On 10/15/2020 2:23 PM, nipun.gu...@nxp.com wrote:
From: Nipun Gupta <nipun.gu...@nxp.com>

This change adds a Rx offload capability and configuration to
enable hardware to drop the packets in case of any error in the
packets such as L3 checksum error or L4 checksum.

Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com>
Signed-off-by: Rohit Raj <rohit....@nxp.com>
Reviewed-by: Asaf Penso <as...@nvidia.com>
---

v4:
  - renamed 'rte_rx_err_pkt_drop_conf' to
    'rte_eth_rx_err_pkt_drop_conf'
  - updated function 'port_offload_cap_display' to display newly
    added offloads
  - added placeholder for L1 FCS, L3 Checksum, L4 Checksum error
    packet drops
  - updated doc/guides/nics/features.rst
  - updated new added 'DEV_RX_OFFLOAD_*' to 'RTE_DEV_RX_OFFLOAD*'
  - updated RX to Rx

v3:
  - Add additional rx_err_drop_offload_capa, which is specific
    capability flag for RX packets error drop offload. Currently
    only 'all' error packet drops are enabled, but can be extended
    to provide capability to drop any specific errors like L1 FCS,
    L3 Checksum etc.
  - Added separate config structure to enable the drop configuration.
  - Updated doc with the new updated option in testbbdev (patch 3/3)

v2:
  - Add support in DPAA1 driver (patch 2/3)
  - Add support and config parameter in testpmd (patch 3/3)

  lib/librte_ethdev/rte_ethdev.c |  1 +
  lib/librte_ethdev/rte_ethdev.h | 39 +++++++++++++++++++++++++++++++++-
  2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c


This feature touches many main parts,
- new config item for 'rte_eth_dev_configure()'
- a new offload flag
- new capability reporting for 'rte_eth_dev_info_get()'

The feature doesn't look very mainstream to touch all these main parts and add complexity to them, which will affect almost all users.

And has some inconsistencies, like configuration is done via config struct, but capability is returned as bit-wise. Or I think config option taken into account only if offload is requested has a chance to confuse people in both app and driver end.

What do you think having two specific APIs to get_capabilities and set drop 
config?
The responsibility of those APIs will be clear and narrowed down, which makes it harder to make it wrong.


Also it is an ABI break as it is and needs to wait 21.11, and even after that it has a potential to cause more ABI breaks, like trying to add a new error type to drop will need to wait 22.11 ..., but if we can have them as separate APIs we can have them as experimental without waiting next LTS.

Reply via email to