Re: [dpdk-dev] Questions about keeping CRC

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 3/19/2021 5:02 PM, Lance Richardson wrote:
> 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.
> 

I think it is more like Stephen said, some HW supports it and software is 
enabling it. It shouldn't hurt the PMD/HW that doesn't support this.