[dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz hash support

Andrew Rybchenko arybchenko at solarflare.com
Sun Sep 29 13:51:26 CEST 2019


On 7/31/19 4:43 PM, Shahaf Shuler wrote:
> Wednesday, July 31, 2019 3:31 PM, Adrien Mazarguil:
>> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz hash
>> support
>>
>> On Wed, Jul 31, 2019 at 03:08:19PM +0300, Andrew Rybchenko wrote:
>>> On 7/25/19 7:57 AM, simei wrote:
>>>> From: Simei Su <simei.su at intel.com>
>>>>
>>>> Currently, there are DEFAULT,TOEPLITZ and SIMPLE_XOR hash funtion.
>>>> To support symmetric hash by rte_flow RSS action, this patch adds
>>>> new hash function "Symmetric Toeplitz" which is supported by some
>> hardware.
>>> Isn't it a question of key to achieve symmetry?
>>> I.e. hash algorithm (function) is still the same - Toeplitz, but hash
>>> key makes the result symmetric (i.e. equal for flows in both
>>> directions - swap transport ports and IPv4/6 addresses).
>> This is only an option when src/dst are known in advance.
>>
>> When doing RSS, HW implementations (such as Mellanox's) implement a
>> modified Toeplitz XOR'ing src with dst resulting in the same hash both ways
>> regardless of the key.
> Just to stand correct it was a bug on Mellanox kernel driver that was fixed. Now the RSS is spec complaint (non-symmetric).
> Andrew is correct one can have a special key that will make the RSS symmetric, however it is good to have this option for the user to explicitly request symmetric function (w/o any restriction on the key).

I think we need a definition what is behind SYMMETRIC_TOEPLITZ here.
If I'd like to test it and check, I need to know an algorithm in order
to know what to expect.
Also it is important to make it the same for all NIC vendors: what
should algorithm be in order to say that it is symmetric Toeplitz?



More information about the dev mailing list