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 for Android: free password hash cracker in your pocket

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

Message-ID: <4f0393fb-7f5a-5e91-ce43-4b2d842dd9b3@intel.com>
Date: Thu, 24 Aug 2023 16:56:33 -0600
From: Ahmed Zaki <ahmed.zaki@...el.com>
To: 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


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.
>>
>>
>> [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.


It has all the info regarding which fields are XOR'd using which 
registers and so on. The hash algorithm itself is the standard Toeplitz, 
also on section 7.10.10.2.