Re: [dpdk-dev] Questions about keeping CRC

[Lance Richardson <lance.richardson@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]

On Fri, Mar 19, 2021 at 12:07 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Fri, 19 Mar 2021 20:13:20 +0800
> "Min Hu (Connor)" <humin29@huawei.com> wrote:
>
> > Hi, all,
> >       DPDK has introduced one offload: DEV_RX_OFFLOAD_KEEP_CRC. It means that
> > the device has the ablility of keeping CRC（four bytes at the end of
> > packet）of packet in RX.
> >       In common scenarios, When one packet enter into NIC device, NIC
> > will check the CRC and then strip the CRC，at last send the packet into
> > the buffer.
> >       So my question is:
> >        why the DEV_RX_OFFLOAD_KEEP_CRC is introduced into DPDK?  I think that
> > when the packet enter into the NIC, the CRC will has no significance to
> > APP. Or is there any scenarios that CRC is useful for APP？
> >       Thanks for your reply.
>
> Your right it doesn't make sense for almost all applications. Maybe an application
> testing for bad NIC hardware might use it.
>
> It is one of those features introduced in DPDK because "our hardware can do it,
> therefore it ought to be exposed in DPDK API"...

The only use case I have seen was in L2 forwarding applications which would
receive packets with CRC preserved and then transmit them with an indication
to the NIC that the CRC should not be regenerated. The idea was that if the
packet was corrupted anywhere in the system (e.g. by a memory error), it
could be detected at the receiver. Of course DPDK doesn't have the notion
of transmitting a packet without regenerating the CRC, so that use case
doesn't seem to apply here.

I think that DEV_RX_OFFLOAD_KEEP_CRC is not likely to be useful, but
I would be interested in hearing otherwise. I happen to know of at least one
PMD that advertises this ability but doesn't actually behave any differently
when it is enabled.