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: <94d9c857-2c2b-77f0-9b17-8088068eee6d@intel.com>
Date: Thu, 24 Aug 2023 07:14:16 -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-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.
>>
>
> Can you please shed more light on the use case and configuration? 
> Where do you expect the same flow/connection rx/tx to be received by the
> same rxq in a nic driver?

The use case is usually an application running on a intermediate server 
(not an endpoint of the flow) monitoring and reading both directions of 
the flow. Applications like intrusion detection systems or user-space 
state-full firewalls. For best CPU and cache efficiencies, we would need 
both flows to land on the same rx queue of that intermediate server. The 
paper in [1] gives more background on Symmetric Toeplitz (but imposes 
some restrictions on the LUT keys to get the hash symmetry).

>
>> Allow ethtool to support symmetric Toeplitz algorithm. A user can set 
>> the
>> RSS function of the netdevice via:
>>    # ethtool -X eth0 hfunc symmetric_toeplitz
>>
>
> 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)

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.

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 



>
>> Signed-off-by: Ahmed Zaki <ahmed.zaki@...el.com>
>> ---
>> include/linux/ethtool.h | 4 +++-
>> net/ethtool/common.c    | 1 +
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index 62b61527bcc4..9a8e1fb7170d 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -60,10 +60,11 @@ enum {
>>     ETH_RSS_HASH_TOP_BIT, /* Configurable RSS hash function - 
>> Toeplitz */
>>     ETH_RSS_HASH_XOR_BIT, /* Configurable RSS hash function - Xor */
>>     ETH_RSS_HASH_CRC32_BIT, /* Configurable RSS hash function - Crc32 */
>> +    ETH_RSS_HASH_SYM_TOP_BIT, /* Configurable RSS hash function - 
>> Symmetric Toeplitz */
>>
>>     /*
>>      * Add your fresh new hash function bits above and remember to 
>> update
>> -     * rss_hash_func_strings[] in ethtool.c
>> +     * rss_hash_func_strings[] in ethtool/common.c
>>      */
>>     ETH_RSS_HASH_FUNCS_COUNT
>> };
>> @@ -108,6 +109,7 @@ enum ethtool_supported_ring_param {
>> #define __ETH_RSS_HASH(name) 
>> __ETH_RSS_HASH_BIT(ETH_RSS_HASH_##name##_BIT)
>>
>> #define ETH_RSS_HASH_TOP    __ETH_RSS_HASH(TOP)
>> +#define ETH_RSS_HASH_SYM_TOP    __ETH_RSS_HASH(SYM_TOP)
>> #define ETH_RSS_HASH_XOR    __ETH_RSS_HASH(XOR)
>> #define ETH_RSS_HASH_CRC32    __ETH_RSS_HASH(CRC32)
>>
>> diff --git a/net/ethtool/common.c b/net/ethtool/common.c
>> index f5598c5f50de..a0e0c6b2980e 100644
>> --- a/net/ethtool/common.c
>> +++ b/net/ethtool/common.c
>> @@ -81,6 +81,7 @@ 
>> rss_hash_func_strings[ETH_RSS_HASH_FUNCS_COUNT][ETH_GSTRING_LEN] = {
>>     [ETH_RSS_HASH_TOP_BIT] =    "toeplitz",
>>     [ETH_RSS_HASH_XOR_BIT] =    "xor",
>>     [ETH_RSS_HASH_CRC32_BIT] =    "crc32",
>> +    [ETH_RSS_HASH_SYM_TOP_BIT] =    "symmetric_toeplitz",
>> };
>>
>> const char
>> -- 
>> 2.39.2
>>
>>