All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Min Hu (Connor)" <humin29@huawei.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] Questions about keeping CRC
Date: Fri, 19 Mar 2021 09:06:53 -0700	[thread overview]
Message-ID: <20210319090653.22b430ea@hermes.local> (raw)
In-Reply-To: <3ddef567-d7ee-5364-cf42-81118a7153ee@huawei.com>

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

  reply	other threads:[~2021-03-19 16:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 12:13 [dpdk-dev] Questions about keeping CRC Min Hu (Connor)
2021-03-19 16:06 ` Stephen Hemminger [this message]
2021-03-19 17:02   ` Lance Richardson
2021-03-22 10:53     ` Ferruh Yigit
2021-03-22 11:38       ` Min Hu (Connor)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210319090653.22b430ea@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=humin29@huawei.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.