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: <ee942349-d8b9-c31d-fa81-a0e82d0f3cda@intel.com>
Date: Fri, 25 Aug 2023 15:21:54 -0600
From: Ahmed Zaki <ahmed.zaki@...el.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
CC: <netdev@...r.kernel.org>, <jesse.brandeburg@...el.com>,
	<anthony.l.nguyen@...el.com>, Saeed Mahameed <saeed@...nel.org>
Subject: Re: [RFC PATCH net-next 1/3] net: ethtool: add symmetric Toeplitz RSS
 hash function


On 2023-08-24 17:30, Willem de Bruijn wrote:
> 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?


Thanks, I was wondering why everyone was assuming "sorted" fileds.

If we go with an a new algorithm (-X hfunc) I agree we should name it 
"xor-symmetric".

I also just suggested to Jakub to use a flag instead of a new algorithm, 
since the underlying algorithm is really just the regular Toeplitz.