On Fri, 19 Jul 2024 17:04:15 +0800
Jie Hai <haij...@huawei.com> wrote:
> From: Dengdui Huang <huangdeng...@huawei.com>
>
> When KEEP_CRC offload is enabled, the CRC data is still stripped
> in following cases:
> 1. For HIP08 network engine, the packet type is TCP and the length
> is less than or equal to 60B.
> 2. For HIP09 network engine, the packet type is IP and the length
> is less than or equal to 60B.
>
> So driver has to recaculate packet CRC for this rare scenarios.
>
> In addition, to avoid impacting performance, KEEP_CRC is not
> supported when NEON or SVE algorithm is used.
>
> Fixes: 8973d7c4ca12 ("net/hns3: support keeping CRC")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dengdui Huang <huangdeng...@huawei.com>
> Acked-by: Huisong Li <lihuis...@huawei.com>
> Acked-by: Jie Hai <haij...@huawei.com>
Changed my mind on these patches after digging deeper into
what other drivers are doing. The proposed patches for hns3 do
the opposite of what the consensus of drivers is.
When looking at internals, all other drivers do not include the CRC
in the packet length calculation. It is hard to go back and determine
the rational for this, but my assumption is that if a packet is received
(with KEEP_CRC enabled), the application will likely want to send that
packet to another location, and the transmit side doesn't want the CRC.
There are a couple of related driver bugs in some drivers in handling
of the flag as well. One driver (idpf) thinks the CRC should count for the byte
statistics. This should be clarified and fixed.
One driver (atlantic) adds a check but doesn't implement the flag; the check for
valid offload flags is already handled by ethdev API.
Please resubmit for a later release, and can be picked up then by 24.11 stable.
You have found an area of DPDK which is poorly documented. Will raise an
agenda at next techboard to get a final agreement, then put that into
the programmer's guide.
