[dpdk-dev] Questions about keeping CRC

[dpdk-dev] Questions about keeping CRC

[Min Hu (Connor)]

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.

Re: [dpdk-dev] Questions about keeping CRC

[Stephen Hemminger]

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"...

Re: [dpdk-dev] Questions about keeping CRC

[Lance Richardson]

[-- 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.

Re: [dpdk-dev] Questions about keeping CRC

[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.

Re: [dpdk-dev] Questions about keeping CRC

[Min Hu (Connor)]

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.
> .