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: <ZOejNYJgR74JGRse@x130>
Date: Thu, 24 Aug 2023 11:36:37 -0700
From: Saeed Mahameed <saeed@...nel.org>
To: Ahmed Zaki <ahmed.zaki@...el.com>
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

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.
>
>
>[1] https://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf
>
>[2] E810 datasheet: 7.10.10.2 : Symmetric Hash
>
>https://www.intel.com/content/www/us/en/content-details/613875/intel-ethernet-controller-e810-datasheet.html
>

This document doesn't mention anything about implementation.