[dpdk-stable] [PATCH v1] net/ixgbe: adjust error for UDP with zero checksum

[Wang, Haiyue]

Hi David,

> -----Original Message-----
> From: David Marchand <david.marchand at redhat.com>
> Sent: Tuesday, February 2, 2021 17:45
> To: Wang, Haiyue <haiyue.wang at intel.com>
> Cc: dev <dev at dpdk.org>; pvalerio at redhat.com; Aaron Conole <aconole at redhat.com>; Zhang, Qi Z
> <qi.z.zhang at intel.com>; Rong, Leyi <leyi.rong at intel.com>; Tu, Lijuan <lijuan.tu at intel.com>; dpdk
> stable <stable at dpdk.org>; Guo, Jia <jia.guo at intel.com>; Richardson, Bruce <bruce.richardson at intel.com>;
> Ananyev, Konstantin <konstantin.ananyev at intel.com>; Jerin Jacob Kollanukkaran <jerinj at marvell.com>;
> Ruifeng Wang (Arm Technology China) <ruifeng.wang at arm.com>
> Subject: Re: [PATCH v1] net/ixgbe: adjust error for UDP with zero checksum
> 
> Hello Haiyue,
> 
> Thanks for working on it quickly.
> Cc: ARM maintainers.
> 
> On Tue, Feb 2, 2021 at 8:23 AM Haiyue Wang <haiyue.wang at intel.com> wrote:
> >
> > There is an 82599 errata that UDP frames with a zero checksum are
> > incorrectly marked as checksum invalid by the hardware.  This was
> 
> Maybe add a reference to the 82599 hw errata, is this listed in the datasheet?
> 

I didn't find open and official doc, but on:

https://www.mouser.es/pdfdocs/82599specupdate.pdf

44 Integrity Error Reported for IPv4/UDP Packets
With Zero Checksum
Problem: According to the UDP specification “an all zero transmitted checksum value
means that the transmitter generated no checksum (for debugging or for higher
level protocols that don’t care)”, these packets should be received without a
checksum error notation. The 82599 reports an L4 integrity error if such packets
are received.
Implication: UDP packets without a checksum will have an L4 integrity error indication in the
Rx descriptor.
Workaround: If bits L4E and L4I are set in the Rx descriptor, the software driver should
check if the checksum is zero and then ignore this error.
Status: B0=Yes; No Fix

> 
> > leading to misleading PKT_RX_L4_CKSUM_BAD flag. This patch adds a
> > test around this checksum error flag set for this condition.
> >
> > 1. UDP Test
> >   sendp(Ether()/IP()/UDP(chksum=0)/Raw("a"*100), iface="ens802f0")
> >   port 0/queue 0: received 1 packets
> >     ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD
> >
> > 2. TCP Test
> >   sendp(Ether()/IP()/TCP(chksum=0)/Raw("a"*100), iface="ens802f0")
> >   port 0/queue 0: received 1 packets
> >     ol_flags: PKT_RX_L4_CKSUM_BAD PKT_RX_IP_CKSUM_GOOD
> >
> > Bugzilla ID: 629
> 
> The problem has always been present, so I would flag:
> Fixes: af75078fece3 ("first public release")
> 
> > Cc: stable at dpdk.org
> >
> 
> Reported-by: Paolo Valerio <pvalerio at redhat.com>
> > Signed-off-by: Haiyue Wang <haiyue.wang at intel.com>
> > ---
> >  doc/guides/nics/ixgbe.rst              |  6 ++++
> >  drivers/net/ixgbe/ixgbe_rxtx.c         | 27 +++++++++++---
> >  drivers/net/ixgbe/ixgbe_rxtx.h         |  2 ++
> >  drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 49 ++++++++++++++++++++------
> >  4 files changed, 70 insertions(+), 14 deletions(-)
> >
> > diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
> > index 696cbd93b..de210b7b8 100644
> > --- a/doc/guides/nics/ixgbe.rst
> > +++ b/doc/guides/nics/ixgbe.rst
> > @@ -287,6 +287,12 @@ the VFs which are required.::
> >  Currently hot-plugging of representor ports is not supported so all required
> >  representors must be specified on the creation of the PF.
> >
> > +Limitations or Known issues
> > +---------------------------
> > +The 82599 hardware errata: UDP frames with a zero checksum can be marked as
> > +checksum errors. To support zero checksum, the UDP checksum is always marked
> > +as good.
> > +
> 
> If the driver/hw can't report a valid checksum hint, it should
> announce it does not know if the checksum is valid (neither bad, nor
> good).
> 
> So the workaround for udp packets (on this hw model) would be to
> report PKT_RX_L4_CKSUM_UNKNOWN.
> The sw application will then have to recompute the checksum itself if needed.
> 

Make sense, but not sure the vector path can handle this more easily. Will try.

> 
> --
> David Marchand