DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wang, Haiyue" <haiyue.wang@intel.com>
To: Paolo Valerio <pvalerio@redhat.com>
Cc: "Guo, Jia" <jia.guo@intel.com>, Aaron Conole <aconole@redhat.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] ixgbe and UDP with zero checksum
Date: Fri, 29 Jan 2021 02:02:06 +0000	[thread overview]
Message-ID: <BN8PR11MB37957906700B261C6882851EF7B99@BN8PR11MB3795.namprd11.prod.outlook.com> (raw)
In-Reply-To: <87im7i12si.fsf@fed.void>

> -----Original Message-----
> From: Paolo Valerio <pvalerio@redhat.com>
> Sent: Thursday, January 28, 2021 05:35
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: Guo, Jia <jia.guo@intel.com>; Aaron Conole <aconole@redhat.com>; dev@dpdk.org
> Subject: RE: ixgbe and UDP with zero checksum
> 
> "Wang, Haiyue" <haiyue.wang@intel.com> writes:
> 
> > Hi Paolo,
> >
> >> -----Original Message-----
> >> From: Paolo Valerio <pvalerio@redhat.com>
> >> Sent: Wednesday, January 27, 2021 21:50
> >> To: dev@dpdk.org
> >> Cc: Guo, Jia <jia.guo@intel.com>; Wang, Haiyue <haiyue.wang@intel.com>; Aaron Conole
> >> <aconole@redhat.com>
> >> Subject: ixgbe and UDP with zero checksum
> >>
> >> Hi,
> >>
> >> performing some tests, I noticed that on ixgbe when receiving UDP
> >> packets with zero checksum (no checksum) over IPv4, the corresponding
> >> ol_flag for the l4 checksum is set to PKT_RX_L4_CKSUM_BAD.
> >>
> >> In particular, this apparently has an impact on OvS using ct() action
> >> where UDP packets with zero checksum are not tracked because of that.
> >
> >
> >>
> >> [1]
> >>
> https://patchwork.ozlabs.org/project/netdev/patch/20090724040031.30202.1531.stgit@localhost.localdomai
> >> n/
> >
> > About 12 years old patch, it is hardware errata. For fixing this,
> > have to always disable vector Rx path for 82599, it seems not a
> > good idea to bring in this workaround. :(
> >
> 
> Thanks for the answer.
> Yes, as I mentioned, the patch is old although still meaningful.
> I linked it mostly because it mentions the hw errata.
> 

What's your PCI device ID ? My worked ixgbe:

86:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

I'm wondering if people will complain that the patch will mark the real bad checksum UDP as
GOOD. For handling this correctly, looks like driver needs to check the UDP's checksum value,
if zero, then skip the error information, but this makes driver do the network stack things ...




  reply	other threads:[~2021-01-29  2:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 13:49 Paolo Valerio
2021-01-27 17:26 ` Wang, Haiyue
2021-01-27 18:21   ` Aaron Conole
2021-01-27 21:35   ` Paolo Valerio
2021-01-29  2:02     ` Wang, Haiyue [this message]
2021-01-29  2:59       ` Wang, Haiyue
2021-01-29 14:19         ` Paolo Valerio
2021-02-02  7:41           ` Wang, Haiyue
2021-02-02  9:33             ` [dpdk-dev] 回复: " Feifei Wang

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=BN8PR11MB37957906700B261C6882851EF7B99@BN8PR11MB3795.namprd11.prod.outlook.com \
    --to=haiyue.wang@intel.com \
    --cc=aconole@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jia.guo@intel.com \
    --cc=pvalerio@redhat.com \
    /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 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).