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: <20230523142005.3c5cc655@kernel.org>
Date: Tue, 23 May 2023 14:20:05 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Louis Peens <louis.peens@...igine.com>, David Miller
 <davem@...emloft.net>, Simon Horman <simon.horman@...igine.com>,
 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 Tue, 23 May 2023 12:49:06 +0200 Paolo Abeni wrote:
> > Previously, since the introduction of the driver, RSS hashing
> > was only performed on the source and destination IP addresses
> > of UDP packets thereby limiting UDP traffic to a single queue
> > for multiple connections on the same IP address. The transport
> > layer is now included in RSS hashing for UDP traffic, which
> > was not previously the case. The reason behind the previous
> > limitation is unclear - either a historic limitation of the
> > NFP device, or an oversight.  
> 
> FTR including the transport header in RSS hash for UDP will damage
> fragmented traffic, but whoever is relaying on fragments nowadays
> should have already at least a dedicated setup.

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?