DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Questions about keeping CRC
@ 2021-03-19 12:13 Min Hu (Connor)
  2021-03-19 16:06 ` Stephen Hemminger
  0 siblings, 1 reply; 5+ messages in thread
From: Min Hu (Connor) @ 2021-03-19 12:13 UTC (permalink / raw)
  To: dev, Ferruh Yigit, Thomas Monjalon

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Questions about keeping CRC
  2021-03-19 12:13 [dpdk-dev] Questions about keeping CRC Min Hu (Connor)
@ 2021-03-19 16:06 ` Stephen Hemminger
  2021-03-19 17:02   ` Lance Richardson
  0 siblings, 1 reply; 5+ messages in thread
From: Stephen Hemminger @ 2021-03-19 16:06 UTC (permalink / raw)
  To: Min Hu (Connor); +Cc: dev, Ferruh Yigit, Thomas Monjalon

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Questions about keeping CRC
  2021-03-19 16:06 ` Stephen Hemminger
@ 2021-03-19 17:02   ` Lance Richardson
  2021-03-22 10:53     ` Ferruh Yigit
  0 siblings, 1 reply; 5+ messages in thread
From: Lance Richardson @ 2021-03-19 17:02 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: Min Hu (Connor), dev, Ferruh Yigit, Thomas Monjalon

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Questions about keeping CRC
  2021-03-19 17:02   ` Lance Richardson
@ 2021-03-22 10:53     ` Ferruh Yigit
  2021-03-22 11:38       ` Min Hu (Connor)
  0 siblings, 1 reply; 5+ messages in thread
From: Ferruh Yigit @ 2021-03-22 10:53 UTC (permalink / raw)
  To: Lance Richardson, Stephen Hemminger
  Cc: Min Hu (Connor), dev, Thomas Monjalon, Andrew Rybchenko

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] Questions about keeping CRC
  2021-03-22 10:53     ` Ferruh Yigit
@ 2021-03-22 11:38       ` Min Hu (Connor)
  0 siblings, 0 replies; 5+ messages in thread
From: Min Hu (Connor) @ 2021-03-22 11:38 UTC (permalink / raw)
  To: Ferruh Yigit, Lance Richardson, Stephen Hemminger
  Cc: dev, Thomas Monjalon, Andrew Rybchenko

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-03-22 11:38 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-19 12:13 [dpdk-dev] Questions about keeping CRC Min Hu (Connor)
2021-03-19 16:06 ` Stephen Hemminger
2021-03-19 17:02   ` Lance Richardson
2021-03-22 10:53     ` Ferruh Yigit
2021-03-22 11:38       ` Min Hu (Connor)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).