netdev - Re: [RFC PATCH net-next 1/3] net: ethtool: add symmetric Toeplitz RSS hash function

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: <64e7e80c13b60_4b65d29437@willemb.c.googlers.com.notmuch>
Date: Thu, 24 Aug 2023 19:30:20 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Ahmed Zaki <ahmed.zaki@...el.com>, 
 Saeed Mahameed <saeed@...nel.org>
Cc: netdev@...r.kernel.org, 
 jesse.brandeburg@...el.com, 
 anthony.l.nguyen@...el.com
Subject: Re: [RFC PATCH net-next 1/3] net: ethtool: add symmetric Toeplitz RSS
 hash function

Ahmed Zaki wrote:
> 
> On 2023-08-24 12:36, Saeed Mahameed wrote:
> > On 24 Aug 07:14, Ahmed Zaki wrote:
> >>
> >> On 2023-08-23 13:45, Saeed Mahameed wrote:
> >>> On 23 Aug 10:48, Ahmed Zaki wrote:
> >>>> Symmetric RSS hash functions are beneficial in applications that 
> >>>> monitor
> >>>> both Tx and Rx packets of the same flow (IDS, software firewalls, 
> >>>> ..etc).
> >>>> Getting all traffic of the same flow on the same RX queue results in
> >>>> higher CPU cache efficiency.
> >>>>
> >
> > ...
> >
> >>>
> >>> What is the expectation of the symmetric toeplitz hash, how do you 
> >>> achieve
> >>> that? by sorting packet fields? which fields?
> >>>
> >>> Can you please provide a link to documentation/spec?
> >>> We should make sure all vendors agree on implementation and 
> >>> expectation of
> >>> the symmetric hash function.
> >>
> >> The way the Intel NICs are achieving this hash symmetry is by XORing 
> >> the source and destination values of the IP and L4 ports and then 
> >> feeding these values to the regular Toeplitz (in-tree) hash algorithm.
> >>
> >> For example, for UDP/IPv4, the input fields for the Toeplitz hash 
> >> would be:
> >>
> >> (SRC_IP, DST_IP, SRC_PORT,  DST_PORT)
> >>
> >
> > So you mangle the input. This is different than the paper you
> > referenced below which doesn't change the input but it modifies the RSS
> > algorithm and uses a special hash key.
> >
> >> If symmetric Toeplitz is set, the NIC XOR the src and dst fields:
> >>
> >> (SRC_IP^DST_IP ,  SRC_IP^DST_IP, SRC_PORT^DST_PORT, SRC_PORT^DST_PORT)
> >>
> >> This way, the output hash would be the same for both flow directions. 
> >> Same is applicable for IPv6, TCP and SCTP.
> >>
> >
> > I understand the motivation, I just want to make sure the 
> > interpretation is
> > clear, I agree with Jakub, we should use a clear name for the ethtool
> > parameter or allow users to select "xor-ed"/"sorted" fields as Jakub
> > suggested.
> >> Regarding the documentation, the above is available in our public 
> >> datasheets [2]. In the final version, I can add similar explanation 
> >> in the headers (kdoc) and under "Documentation/networking/" so that 
> >> there is a clear understanding of the algorithm.

Please do define the behavior.

When I hear symmetric Toeplitz, my initial assumption was also
sorted fields, as implemented in __flow_hash_consistentify.

If this is something else, agreed that that is good to make
crystal clear in name and somewhere in the kernel Documentation.
xor-symmetric hash?