[dpdk-dev] [PATCH 1/3 v4] ethdev: add Rx offload to drop error packets

Ferruh Yigit ferruh.yigit at intel.com
Thu Feb 18 21:32:54 CET 2021


On 10/15/2020 2:23 PM, nipun.gupta at nxp.com wrote:
> From: Nipun Gupta <nipun.gupta at 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.gupta at nxp.com>
> Signed-off-by: Rohit Raj <rohit.raj at nxp.com>
> Reviewed-by: Asaf Penso <asafp at 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.


More information about the dev mailing list