[1/2] ethdev: add symmetric toeplitz hash support

Message ID 1564030646-73951-2-git-send-email-simei.su@intel.com (mailing list archive)
State Superseded, archived
Delegated to: Ferruh Yigit
Headers
Series add symmetric toeplitz hash support |

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/Intel-compilation success Compilation OK
ci/iol-Compile-Testing success Compile Testing PASS
ci/mellanox-Performance-Testing success Performance Testing PASS
ci/intel-Performance-Testing success Performance Testing PASS

Commit Message

Simei Su July 25, 2019, 4:57 a.m. UTC
  From: Simei Su <simei.su@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.

Signed-off-by: Simei Su <simei.su@intel.com>
---
 lib/librte_ethdev/rte_flow.h | 1 +
 1 file changed, 1 insertion(+)
  

Comments

Andrew Rybchenko July 31, 2019, 12:08 p.m. UTC | #1
On 7/25/19 7:57 AM, simei wrote:
> From: Simei Su <simei.su@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).

> Signed-off-by: Simei Su <simei.su@intel.com>
> ---
>   lib/librte_ethdev/rte_flow.h | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index f3a8fb1..2a0e6d5 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -1744,6 +1744,7 @@ enum rte_eth_hash_function {
>   	RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
>   	RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
>   	RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
> +	RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ, /**< Symmetric Toeplitz */
>   	RTE_ETH_HASH_FUNCTION_MAX,
>   };
>   
>
  
Adrien Mazarguil July 31, 2019, 12:30 p.m. UTC | #2
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@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.
  
Andrew Rybchenko July 31, 2019, 1:03 p.m. UTC | #3
On 7/31/19 3:30 PM, Adrien Mazarguil wrote:
> 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@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.

OK, I see. But generic symmetric Toeplitz is introduced by the patch.
What is criteria for other vendor to say that it is supported?
What should application expect?
The algorithm should be defined.

Also interesting question is how does it co-exists with the other
patch in the mailing list which introduces way to use source or
destination IP/port only.
  
Shahaf Shuler July 31, 2019, 1:43 p.m. UTC | #4
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@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).

> 
> --
> Adrien Mazarguil
> 6WIND
  
Andrew Rybchenko Sept. 29, 2019, 11:51 a.m. UTC | #5
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@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?
  
Simei Su Sept. 30, 2019, 3:12 a.m. UTC | #6
Hi, Andrew

> -----Original Message-----
> From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
> Sent: Sunday, September 29, 2019 7:51 PM
> To: Shahaf Shuler <shahafs@mellanox.com>; Adrien Mazarguil
> <adrien.mazarguil@6wind.com>
> Cc: Su, Simei <simei.su@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu,
> Jingjing <jingjing.wu@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz hash
> support
> 
> 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@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?

The symmetric toeplitz is: src, dst will be replaced by xor(src, dst).
It is expected to get the same hash value when swapping src/dst ip or port.

Br
Simei
  
Andrew Rybchenko Sept. 30, 2019, 6:14 a.m. UTC | #7
Hi Simei,

On 9/30/19 6:12 AM, Su, Simei wrote:
> Hi, Andrew
>
>> -----Original Message-----
>> From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
>> Sent: Sunday, September 29, 2019 7:51 PM
>> To: Shahaf Shuler <shahafs@mellanox.com>; Adrien Mazarguil
>> <adrien.mazarguil@6wind.com>
>> Cc: Su, Simei <simei.su@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu,
>> Jingjing <jingjing.wu@intel.com>; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz hash
>> support
>>
>> 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@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?
> The symmetric toeplitz is: src, dst will be replaced by xor(src, dst).
> It is expected to get the same hash value when swapping src/dst ip or port.

Are both replaced by XOR or just one is replaced by XOR and another one
removed from Toeplitz input? If later, how does it coexist with src/dst only
flags?

Anyway, please, add it to the patch in Doxygen comments.

Thanks,
Andrew.
  
Simei Su Sept. 30, 2019, 6:34 a.m. UTC | #8
Hi, Andrew

> -----Original Message-----
> From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
> Sent: Monday, September 30, 2019 2:15 PM
> To: Su, Simei <simei.su@intel.com>; Shahaf Shuler <shahafs@mellanox.com>;
> Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz hash
> support
> 
> Hi Simei,
> 
> On 9/30/19 6:12 AM, Su, Simei wrote:
> > Hi, Andrew
> >
> >> -----Original Message-----
> >> From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
> >> Sent: Sunday, September 29, 2019 7:51 PM
> >> To: Shahaf Shuler <shahafs@mellanox.com>; Adrien Mazarguil
> >> <adrien.mazarguil@6wind.com>
> >> Cc: Su, Simei <simei.su@intel.com>; Zhang, Qi Z
> >> <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> >> dev@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz
> >> hash support
> >>
> >> 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@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?
> > The symmetric toeplitz is: src, dst will be replaced by xor(src, dst).
> > It is expected to get the same hash value when swapping src/dst ip or port.
> 
> Are both replaced by XOR or just one is replaced by XOR and another one
> removed from Toeplitz input? If later, how does it coexist with src/dst only flags?
> 
> Anyway, please, add it to the patch in Doxygen comments.
> 
  In our case, src and dst are both replaced by XOR. For example, src ip and dst ip or src port and dst port are swapped, the hash value is the same.
  SRC/DST only flags is another thing, it covers input set change.

Br
Simei

> Thanks,
> Andrew.
  
Qi Zhang Sept. 30, 2019, 7:49 a.m. UTC | #9
> -----Original Message-----
> From: Su, Simei
> Sent: Monday, September 30, 2019 2:34 PM
> To: Andrew Rybchenko <arybchenko@solarflare.com>; Shahaf Shuler
> <shahafs@mellanox.com>; Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz hash
> support
> 
> Hi, Andrew
> 
> > -----Original Message-----
> > From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
> > Sent: Monday, September 30, 2019 2:15 PM
> > To: Su, Simei <simei.su@intel.com>; Shahaf Shuler
> > <shahafs@mellanox.com>; Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
> > <jingjing.wu@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz
> > hash support
> >
> > Hi Simei,
> >
> > On 9/30/19 6:12 AM, Su, Simei wrote:
> > > Hi, Andrew
> > >
> > >> -----Original Message-----
> > >> From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
> > >> Sent: Sunday, September 29, 2019 7:51 PM
> > >> To: Shahaf Shuler <shahafs@mellanox.com>; Adrien Mazarguil
> > >> <adrien.mazarguil@6wind.com>
> > >> Cc: Su, Simei <simei.su@intel.com>; Zhang, Qi Z
> > >> <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> > >> dev@dpdk.org
> > >> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz
> > >> hash support
> > >>
> > >> 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@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?
> > > The symmetric toeplitz is: src, dst will be replaced by xor(src, dst).
> > > It is expected to get the same hash value when swapping src/dst ip or port.
> >
> > Are both replaced by XOR or just one is replaced by XOR and another
> > one removed from Toeplitz input? If later, how does it coexist with src/dst
> only flags?
> >
> > Anyway, please, add it to the patch in Doxygen comments.
> >
>   In our case, src and dst are both replaced by XOR. For example, src ip and
> dst ip or src port and dst port are swapped, the hash value is the same.
>   SRC/DST only flags is another thing, it covers input set change.

For the case with dst / src only, src or dst address will XOR with zero pair, so it result same value as simple Toeplitz

> 
> Br
> Simei
> 
> > Thanks,
> > Andrew.
  

Patch

diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index f3a8fb1..2a0e6d5 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -1744,6 +1744,7 @@  enum rte_eth_hash_function {
 	RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
 	RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
 	RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
+	RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ, /**< Symmetric Toeplitz */
 	RTE_ETH_HASH_FUNCTION_MAX,
 };