netdev - Re: [PATCH net-next] nfp: add L4 RSS hashing on UDP traffic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF=yD-JH2NHTXCg-Z=cUw-JK0g9Y9pb-pcyboq5AkES+ohShkg@mail.gmail.com>
Date: Wed, 24 May 2023 11:33:15 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Simon Horman <simon.horman@...igine.com>, Paolo Abeni <pabeni@...hat.com>, 
	Louis Peens <louis.peens@...igine.com>, David Miller <davem@...emloft.net>, netdev@...r.kernel.org, 
	oss-drivers@...igine.com, Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net-next] nfp: add L4 RSS hashing on UDP traffic

On Wed, May 24, 2023 at 11:22 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Wed, 24 May 2023 13:30:06 +0200 Simon Horman wrote:
> > On Tue, May 23, 2023 at 02:20:05PM -0700, Jakub Kicinski wrote:
> > > Yup, that's the exact reason it was disabled by default, FWIW.
> > >
> > > The Microsoft spec is not crystal clear on how to handles this:
> > > https://learn.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-types#ndis_hash_ipv4
> > > There is a note saying:
> > >
> > >   If a NIC receives a packet that has both IP and TCP headers,
> > >   NDIS_HASH_TCP_IPV4 should not always be used. In the case of a
> > >   fragmented IP packet, NDIS_HASH_IPV4 must be used. This includes
> > >   the first fragment which contains both IP and TCP headers.
> > >
> > > While NDIS_HASH_UDP_IPV4 makes no such distinction and talks only about
> > > "presence" of the header.
> > >
> > > Maybe we should document that device is expected not to use the UDP
> > > header if MF is set?
> >
> > Yes, maybe.
> >
> > Could you suggest where such documentation should go?
>
> That's the hardest question, perhaps :)
>
> Documentation/networking/scaling.rst and/or OCP NIC spec:
>
> https://ocp-all.groups.io/g/OCP-Networking/topic/nic_software_core_offloads/98930671?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,98930671,previd%3D1684255676674808204,nextid%3D1676673801962532335&previd=1684255676674808204&nextid=1676673801962532335

The OCP draft spec already has this wording, which covers UDP:

"RSS defines two rules to derive queue selection input in a
flow-affine manner from packet headers. Selected fields of the headers
are extracted and concatenated into a byte array. If the packet is
IPv4 or IPv6, not fragmented, and followed by a transport layer
protocol with ports, such as TCP and UDP, then extract the
concatenated 4-field byte array { source address, destination address,
source port, destination port }. Else, if the packet is IPv4 or IPv6,
extract 2-field byte array { source address, destination address }.
IPv4 packets are considered fragmented if the more fragments bit is
set or the fragment offset field is non-zero."

Non google docs version:
https://www.opencompute.org/w/index.php?title=Core_Offloads