Re: [dpdk-dev] Questions about keeping CRC

["Min Hu (Connor)" <humin29@huawei.com>]

Hi, Lance ,Stephen and Ferruh,
	Got it, thanks for your reply.

在 2021/3/22 18:53, Ferruh Yigit 写道:
> 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.
> .