[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Kamraan Nasim]

Hello,

So i've borrowed some code from the DPDK Load balancer sample application,
specifically the load balancing position(byte 29th) to determine which
worker lcore to forward the packet to.

The idea is that flow affinity should be maintained and all packets from
the same flow would have the same checksum/5-tuple value

worker_id = packet[load_balancing_field] % n_workers

Question is that how reliable is this load balancing position? I am tempted
to use Hash tables but I think this position based mechanism may be faster.

How have people's experience with this been in general?


--Kam

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Bruce Richardson]

On Thu, Nov 13, 2014 at 01:29:32PM -0500, Kamraan Nasim wrote:
> Hello,
> 
> So i've borrowed some code from the DPDK Load balancer sample application,
> specifically the load balancing position(byte 29th) to determine which
> worker lcore to forward the packet to.
> 
> The idea is that flow affinity should be maintained and all packets from
> the same flow would have the same checksum/5-tuple value
> 
> worker_id = packet[load_balancing_field] % n_workers
> 
> Question is that how reliable is this load balancing position? I am tempted
> to use Hash tables but I think this position based mechanism may be faster.
> 
> How have people's experience with this been in general?
>

Using a modulus "%" operation will be far, far faster than doing a hash table
lookup, though obviously it is not as flexible. [If you have a power-of-two
number of workers, you can replace the "%" by "&", if you like to shave off
another few cycles].
As for reliability, I'm afraid it depends entirely on your application and what
field you pick as to whether it works for load balancing or not. 

/Bruce

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Ananyev, Konstantin]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Kamraan Nasim
> Sent: Thursday, November 13, 2014 6:30 PM
> To: dev@dpdk.org
> Cc: Yuanzhang Hu
> Subject: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
> 
> Hello,
> 
> So i've borrowed some code from the DPDK Load balancer sample application,
> specifically the load balancing position(byte 29th) to determine which
> worker lcore to forward the packet to.
> 
> The idea is that flow affinity should be maintained and all packets from
> the same flow would have the same checksum/5-tuple value
> 
> worker_id = packet[load_balancing_field] % n_workers
> 
> Question is that how reliable is this load balancing position? I am tempted
> to use Hash tables but I think this position based mechanism may be faster.
> 
> How have people's experience with this been in general?

If you have a NIC that is capable to do HW hash computation,
then you can do your load balancing based on that value.
Let say ixgbe/igb/i40e NICs can calculate RSS hash value based on different combinations of 
dst/src Ips, dst/src ports.
This value can be stored inside mbuf for each RX packet by PMD RX function.
Then you can do:
worker_id = mbuf->hash.rss % n_workersl

That might to provide better balancing then using just one byte value,
plus should be a bit faster, as in that case your balancer code don't need to touch packet's data.   

Konstantin

> 
> 
> --Kam

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Yerden Zhumabekov]

I'd like to interject a question here.

In case of flow classification, one might possibly prefer for packets
from the same flow to fall on the same logical core. With this '%' load
balancing, it would require to get the same RSS hash value for packets
with direct (src to dst) and swapped (dst to src) IPs and ports. Am I
correct that hardware RSS calculation cannot provide this symmetry?

14.11.2014 20:44, Ananyev, Konstantin пишет:
> If you have a NIC that is capable to do HW hash computation,
> then you can do your load balancing based on that value.
> Let say ixgbe/igb/i40e NICs can calculate RSS hash value based on different combinations of 
> dst/src Ips, dst/src ports.
> This value can be stored inside mbuf for each RX packet by PMD RX function.
> Then you can do:
> worker_id = mbuf->hash.rss % n_workersl
>
> That might to provide better balancing then using just one byte value,
> plus should be a bit faster, as in that case your balancer code don't need to touch packet's data.   
>
> Konstantin

-- 
Sincerely,

Yerden Zhumabekov
State Technical Service
Astana, KZ

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Ananyev, Konstantin]

> -----Original Message-----
> From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz]
> Sent: Friday, November 14, 2014 4:23 PM
> To: Ananyev, Konstantin; Kamraan Nasim; dev@dpdk.org
> Cc: Yuanzhang Hu
> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
> 
> I'd like to interject a question here.
> 
> In case of flow classification, one might possibly prefer for packets
> from the same flow to fall on the same logical core. With this '%' load
> balancing, it would require to get the same RSS hash value for packets
> with direct (src to dst) and swapped (dst to src) IPs and ports. Am I
> correct that hardware RSS calculation cannot provide this symmetry?

As I remember, it is possible but you have to tweak rss key values.
Here is a paper describing how to do that:
http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf

Konstantin

> 
> 14.11.2014 20:44, Ananyev, Konstantin пишет:
> > If you have a NIC that is capable to do HW hash computation,
> > then you can do your load balancing based on that value.
> > Let say ixgbe/igb/i40e NICs can calculate RSS hash value based on different combinations of
> > dst/src Ips, dst/src ports.
> > This value can be stored inside mbuf for each RX packet by PMD RX function.
> > Then you can do:
> > worker_id = mbuf->hash.rss % n_workersl
> >
> > That might to provide better balancing then using just one byte value,
> > plus should be a bit faster, as in that case your balancer code don't need to touch packet's data.
> >
> > Konstantin
> 
> --
> Sincerely,
> 
> Yerden Zhumabekov
> State Technical Service
> Astana, KZ
> 

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Yerden Zhumabekov]

14.11.2014 22:50, Ananyev, Konstantin пишет:
>> -----Original Message-----
>> From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz]
>> Sent: Friday, November 14, 2014 4:23 PM
>> To: Ananyev, Konstantin; Kamraan Nasim; dev@dpdk.org
>> Cc: Yuanzhang Hu
>> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
>>
>> I'd like to interject a question here.
>>
>> In case of flow classification, one might possibly prefer for packets
>> from the same flow to fall on the same logical core. With this '%' load
>> balancing, it would require to get the same RSS hash value for packets
>> with direct (src to dst) and swapped (dst to src) IPs and ports. Am I
>> correct that hardware RSS calculation cannot provide this symmetry?
> As I remember, it is possible but you have to tweak rss key values.
> Here is a paper describing how to do that:
> http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf

Oh, very interesting paper. Thank you for hinting. Need to give it a go.

-- 
Sincerely,

Yerden Zhumabekov
State Technical Service
Astana, KZ

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Chilikin, Andrey]

Fortville supports symmetrical hashing on HW level, a patch for i40e PMD was submitted a couple of weeks ago. For Niantic you can use symmetrical  rss key recommended by Konstantin.

Regards,
Andrey

-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
Sent: Friday, November 14, 2014 4:50 PM
To: Yerden Zhumabekov; Kamraan Nasim; dev@dpdk.org
Cc: Yuanzhang Hu
Subject: Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

> -----Original Message-----
> From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz]
> Sent: Friday, November 14, 2014 4:23 PM
> To: Ananyev, Konstantin; Kamraan Nasim; dev@dpdk.org
> Cc: Yuanzhang Hu
> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK 
> load_balancer sample app vs. Hash table
> 
> I'd like to interject a question here.
> 
> In case of flow classification, one might possibly prefer for packets 
> from the same flow to fall on the same logical core. With this '%' 
> load balancing, it would require to get the same RSS hash value for 
> packets with direct (src to dst) and swapped (dst to src) IPs and 
> ports. Am I correct that hardware RSS calculation cannot provide this symmetry?

As I remember, it is possible but you have to tweak rss key values.
Here is a paper describing how to do that:
http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf

Konstantin

> 
> 14.11.2014 20:44, Ananyev, Konstantin пишет:
> > If you have a NIC that is capable to do HW hash computation, then 
> > you can do your load balancing based on that value.
> > Let say ixgbe/igb/i40e NICs can calculate RSS hash value based on 
> > different combinations of dst/src Ips, dst/src ports.
> > This value can be stored inside mbuf for each RX packet by PMD RX function.
> > Then you can do:
> > worker_id = mbuf->hash.rss % n_workersl
> >
> > That might to provide better balancing then using just one byte 
> > value, plus should be a bit faster, as in that case your balancer code don't need to touch packet's data.
> >
> > Konstantin
> 
> --
> Sincerely,
> 
> Yerden Zhumabekov
> State Technical Service
> Astana, KZ
> 

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Yerden Zhumabekov]

Thank you. And one more thing, does Fortville (or Niantic) support
various L2 headers when calculating RSS hash? I mean MPLS, QinQ, etc.?

14.11.2014 22:57, Chilikin, Andrey пишет:
> Fortville supports symmetrical hashing on HW level, a patch for i40e PMD was submitted a couple of weeks ago. For Niantic you can use symmetrical  rss key recommended by Konstantin.
>
> Regards,
> Andrey
>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Friday, November 14, 2014 4:50 PM
> To: Yerden Zhumabekov; Kamraan Nasim; dev@dpdk.org
> Cc: Yuanzhang Hu
> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
>
>> -----Original Message-----
>> From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz]
>> Sent: Friday, November 14, 2014 4:23 PM
>> To: Ananyev, Konstantin; Kamraan Nasim; dev@dpdk.org
>> Cc: Yuanzhang Hu
>> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK 
>> load_balancer sample app vs. Hash table
>>
>> I'd like to interject a question here.
>>
>> In case of flow classification, one might possibly prefer for packets 
>> from the same flow to fall on the same logical core. With this '%' 
>> load balancing, it would require to get the same RSS hash value for 
>> packets with direct (src to dst) and swapped (dst to src) IPs and 
>> ports. Am I correct that hardware RSS calculation cannot provide this symmetry?
> As I remember, it is possible but you have to tweak rss key values.
> Here is a paper describing how to do that:
> http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf
>
> Konstantin
>

-- 
Sincerely,

Yerden Zhumabekov
State Technical Service
Astana, KZ

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Chilikin, Andrey]

Fortville can calculate hash for packets encapsulated into different tunnels: GRE/NVGRE, VXLAN, QinQ (S-Tag + C-Tag), but at the moment current version of DPDK supports only VXLAN.

Regards,
Andrey

-----Original Message-----
From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz] 
Sent: Friday, November 14, 2014 5:21 PM
To: Chilikin, Andrey; Ananyev, Konstantin; Kamraan Nasim; dev@dpdk.org
Cc: Yuanzhang Hu; Zhang, Helin
Subject: Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

Thank you. And one more thing, does Fortville (or Niantic) support various L2 headers when calculating RSS hash? I mean MPLS, QinQ, etc.?

14.11.2014 22:57, Chilikin, Andrey пишет:
> Fortville supports symmetrical hashing on HW level, a patch for i40e PMD was submitted a couple of weeks ago. For Niantic you can use symmetrical  rss key recommended by Konstantin.
>
> Regards,
> Andrey
>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, 
> Konstantin
> Sent: Friday, November 14, 2014 4:50 PM
> To: Yerden Zhumabekov; Kamraan Nasim; dev@dpdk.org
> Cc: Yuanzhang Hu
> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK 
> load_balancer sample app vs. Hash table
>
>> -----Original Message-----
>> From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz]
>> Sent: Friday, November 14, 2014 4:23 PM
>> To: Ananyev, Konstantin; Kamraan Nasim; dev@dpdk.org
>> Cc: Yuanzhang Hu
>> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK 
>> load_balancer sample app vs. Hash table
>>
>> I'd like to interject a question here.
>>
>> In case of flow classification, one might possibly prefer for packets 
>> from the same flow to fall on the same logical core. With this '%'
>> load balancing, it would require to get the same RSS hash value for 
>> packets with direct (src to dst) and swapped (dst to src) IPs and 
>> ports. Am I correct that hardware RSS calculation cannot provide this symmetry?
> As I remember, it is possible but you have to tweak rss key values.
> Here is a paper describing how to do that:
> http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf
>
> Konstantin
>

--
Sincerely,

Yerden Zhumabekov
State Technical Service
Astana, KZ

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Matt Laswell]

Hey Folks,

This thread has been tremendously helpful, as I'm looking at adding
RSS-based load balancing to my application in the not too distant future.
Many thanks to all who have contributed, especially regarding symmetric RSS.

Not to derail the conversation too badly, but could one of you point me to
some example code that demonstrates the steps needed to configure RSS?
We're using Niantic NICs, so I assume that this is pretty standard stuff,
but having an example to study is a real leg up.

Again, thanks for all of the information.

--
Matt Laswell
laswell@infiniteio.com
infinite io, inc.

On Fri, Nov 14, 2014 at 10:57 AM, Chilikin, Andrey <
andrey.chilikin@intel.com> wrote:

> Fortville supports symmetrical hashing on HW level, a patch for i40e PMD
> was submitted a couple of weeks ago. For Niantic you can use symmetrical
> rss key recommended by Konstantin.
>
> Regards,
> Andrey
>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Friday, November 14, 2014 4:50 PM
> To: Yerden Zhumabekov; Kamraan Nasim; dev@dpdk.org
> Cc: Yuanzhang Hu
> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK
> load_balancer sample app vs. Hash table
>
> > -----Original Message-----
> > From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz]
> > Sent: Friday, November 14, 2014 4:23 PM
> > To: Ananyev, Konstantin; Kamraan Nasim; dev@dpdk.org
> > Cc: Yuanzhang Hu
> > Subject: Re: [dpdk-dev] Load-balancing position field in DPDK
> > load_balancer sample app vs. Hash table
> >
> > I'd like to interject a question here.
> >
> > In case of flow classification, one might possibly prefer for packets
> > from the same flow to fall on the same logical core. With this '%'
> > load balancing, it would require to get the same RSS hash value for
> > packets with direct (src to dst) and swapped (dst to src) IPs and
> > ports. Am I correct that hardware RSS calculation cannot provide this
> symmetry?
>
> As I remember, it is possible but you have to tweak rss key values.
> Here is a paper describing how to do that:
> http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf
>
> Konstantin
>
> >
> > 14.11.2014 20:44, Ananyev, Konstantin пишет:
> > > If you have a NIC that is capable to do HW hash computation, then
> > > you can do your load balancing based on that value.
> > > Let say ixgbe/igb/i40e NICs can calculate RSS hash value based on
> > > different combinations of dst/src Ips, dst/src ports.
> > > This value can be stored inside mbuf for each RX packet by PMD RX
> function.
> > > Then you can do:
> > > worker_id = mbuf->hash.rss % n_workersl
> > >
> > > That might to provide better balancing then using just one byte
> > > value, plus should be a bit faster, as in that case your balancer code
> don't need to touch packet's data.
> > >
> > > Konstantin
> >
> > --
> > Sincerely,
> >
> > Yerden Zhumabekov
> > State Technical Service
> > Astana, KZ
> >
>
>

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Yerden Zhumabekov]

Hello Matt,

You can specify RSS configuration through rte_eth_dev_configure()
function supplied with this structure:

struct rte_eth_conf port_conf = {
    .rxmode = {
        .mq_mode    = ETH_MQ_RX_RSS,
         ...
    },
    .rx_adv_conf = {
        .rss_conf = {
            .rss_key = NULL,
            .rss_hf = ETH_RSS_IPV4 | ETH_RSS_IPV6,
        },
    },
    .....
};

In this case, RSS-hash is calculated over IP addresses only and with
default RSS key. Look at lib/librte_ether/rte_ethdev.h for other
definitions.


15.11.2014 0:49, Matt Laswell пишет:
> Hey Folks,
>
> This thread has been tremendously helpful, as I'm looking at adding
> RSS-based load balancing to my application in the not too distant
> future.  Many thanks to all who have contributed, especially regarding
> symmetric RSS.
>
> Not to derail the conversation too badly, but could one of you point
> me to some example code that demonstrates the steps needed to
> configure RSS?  We're using Niantic NICs, so I assume that this is
> pretty standard stuff, but having an example to study is a real leg up.
>
> Again, thanks for all of the information.
>
> --
> Matt Laswell
> laswell@infiniteio.com <mailto:laswell@infiniteio.com>
> infinite io, inc.
>
> On Fri, Nov 14, 2014 at 10:57 AM, Chilikin, Andrey
> <andrey.chilikin@intel.com <mailto:andrey.chilikin@intel.com>> wrote:
>
>     Fortville supports symmetrical hashing on HW level, a patch for
>     i40e PMD was submitted a couple of weeks ago. For Niantic you can
>     use symmetrical  rss key recommended by Konstantin.
>
>     Regards,
>     Andrey
>
>     -----Original Message-----
>     From: dev [mailto:dev-bounces@dpdk.org
>     <mailto:dev-bounces@dpdk.org>] On Behalf Of Ananyev, Konstantin
>     Sent: Friday, November 14, 2014 4:50 PM
>     To: Yerden Zhumabekov; Kamraan Nasim; dev@dpdk.org
>     <mailto:dev@dpdk.org>
>     Cc: Yuanzhang Hu
>     Subject: Re: [dpdk-dev] Load-balancing position field in DPDK
>     load_balancer sample app vs. Hash table
>
>     > -----Original Message-----
>     > From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz
>     <mailto:e_zhumabekov@sts.kz>]
>     > Sent: Friday, November 14, 2014 4:23 PM
>     > To: Ananyev, Konstantin; Kamraan Nasim; dev@dpdk.org
>     <mailto:dev@dpdk.org>
>     > Cc: Yuanzhang Hu
>     > Subject: Re: [dpdk-dev] Load-balancing position field in DPDK
>     > load_balancer sample app vs. Hash table
>     >
>     > I'd like to interject a question here.
>     >
>     > In case of flow classification, one might possibly prefer for
>     packets
>     > from the same flow to fall on the same logical core. With this '%'
>     > load balancing, it would require to get the same RSS hash value for
>     > packets with direct (src to dst) and swapped (dst to src) IPs and
>     > ports. Am I correct that hardware RSS calculation cannot provide
>     this symmetry?
>
>     As I remember, it is possible but you have to tweak rss key values.
>     Here is a paper describing how to do that:
>     http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf
>     <http://www.ndsl.kaist.edu/%7Eshinae/papers/TR-symRSS.pdf>
>
>     Konstantin
>
>     >
>     > 14.11.2014 20:44, Ananyev, Konstantin пишет:
>     > > If you have a NIC that is capable to do HW hash computation, then
>     > > you can do your load balancing based on that value.
>     > > Let say ixgbe/igb/i40e NICs can calculate RSS hash value based on
>     > > different combinations of dst/src Ips, dst/src ports.
>     > > This value can be stored inside mbuf for each RX packet by PMD
>     RX function.
>     > > Then you can do:
>     > > worker_id = mbuf->hash.rss % n_workersl
>     > >
>     > > That might to provide better balancing then using just one byte
>     > > value, plus should be a bit faster, as in that case your
>     balancer code don't need to touch packet's data.
>     > >
>     > > Konstantin
>     >
>     > --
>     > Sincerely,
>     >
>     > Yerden Zhumabekov
>     > State Technical Service
>     > Astana, KZ
>     >
>
>

-- 
Sincerely,

Yerden Zhumabekov
State Technical Service
Astana, KZ

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Matt Laswell]

Fantastic.  Thanks for the assist.

--
Matt Laswell
laswell@infiniteio.com
infinite io, inc.


On Sat, Nov 15, 2014 at 1:10 AM, Yerden Zhumabekov <e_zhumabekov@sts.kz>
wrote:

>  Hello Matt,
>
> You can specify RSS configuration through rte_eth_dev_configure() function
> supplied with this structure:
>
> struct rte_eth_conf port_conf = {
>     .rxmode = {
>         .mq_mode    = ETH_MQ_RX_RSS,
>          ...
>     },
>     .rx_adv_conf = {
>         .rss_conf = {
>             .rss_key = NULL,
>             .rss_hf = ETH_RSS_IPV4 | ETH_RSS_IPV6,
>         },
>     },
>     .....
> };
>
> In this case, RSS-hash is calculated over IP addresses only and with
> default RSS key. Look at lib/librte_ether/rte_ethdev.h for other
> definitions.
>
>
> 15.11.2014 0:49, Matt Laswell пишет:
>
> Hey Folks,
>
>  This thread has been tremendously helpful, as I'm looking at adding
> RSS-based load balancing to my application in the not too distant future.
> Many thanks to all who have contributed, especially regarding symmetric RSS.
>
>  Not to derail the conversation too badly, but could one of you point me
> to some example code that demonstrates the steps needed to configure RSS?
> We're using Niantic NICs, so I assume that this is pretty standard stuff,
> but having an example to study is a real leg up.
>
>  Again, thanks for all of the information.
>
>  --
> Matt Laswell
> laswell@infiniteio.com
> infinite io, inc.
>
> On Fri, Nov 14, 2014 at 10:57 AM, Chilikin, Andrey <
> andrey.chilikin@intel.com> wrote:
>
>> Fortville supports symmetrical hashing on HW level, a patch for i40e PMD
>> was submitted a couple of weeks ago. For Niantic you can use symmetrical
>> rss key recommended by Konstantin.
>>
>> Regards,
>> Andrey
>>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
>> Sent: Friday, November 14, 2014 4:50 PM
>> To: Yerden Zhumabekov; Kamraan Nasim; dev@dpdk.org
>> Cc: Yuanzhang Hu
>> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK
>> load_balancer sample app vs. Hash table
>>
>> > -----Original Message-----
>> > From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz]
>> > Sent: Friday, November 14, 2014 4:23 PM
>> > To: Ananyev, Konstantin; Kamraan Nasim; dev@dpdk.org
>> > Cc: Yuanzhang Hu
>> > Subject: Re: [dpdk-dev] Load-balancing position field in DPDK
>> > load_balancer sample app vs. Hash table
>> >
>> > I'd like to interject a question here.
>> >
>> > In case of flow classification, one might possibly prefer for packets
>> > from the same flow to fall on the same logical core. With this '%'
>> > load balancing, it would require to get the same RSS hash value for
>> > packets with direct (src to dst) and swapped (dst to src) IPs and
>> > ports. Am I correct that hardware RSS calculation cannot provide this
>> symmetry?
>>
>> As I remember, it is possible but you have to tweak rss key values.
>> Here is a paper describing how to do that:
>> http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf
>>
>> Konstantin
>>
>> >
>> > 14.11.2014 20:44, Ananyev, Konstantin пишет:
>> > > If you have a NIC that is capable to do HW hash computation, then
>> > > you can do your load balancing based on that value.
>> > > Let say ixgbe/igb/i40e NICs can calculate RSS hash value based on
>> > > different combinations of dst/src Ips, dst/src ports.
>> > > This value can be stored inside mbuf for each RX packet by PMD RX
>> function.
>> > > Then you can do:
>> > > worker_id = mbuf->hash.rss % n_workersl
>> > >
>> > > That might to provide better balancing then using just one byte
>> > > value, plus should be a bit faster, as in that case your balancer
>> code don't need to touch packet's data.
>> > >
>> > > Konstantin
>> >
>> > --
>> > Sincerely,
>> >
>> > Yerden Zhumabekov
>> > State Technical Service
>> > Astana, KZ
>> >
>>
>>
>
> --
> Sincerely,
>
> Yerden Zhumabekov
> State Technical Service
> Astana, KZ
>
>

Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table

[Zhang, Helin]

Hi Andrey

Yes, Fortville supports hardware symmetric hashing offload. I am waiting for the
comments of its patch set submitted recently, and hopefully it can be accepted soon.
To use it, we need to enable the hash function of symmetric, but not the default
one of Toeplitz hash function. Then we need to set the swap configurations of it.
In detail, it is to set the offsets and length of the packet contents to be symmetric
hashed.

For more details, please refer to its datasheet (possible chapter of 7.1.10 Hash Functions)!

Regards,
Helin

> -----Original Message-----
> From: Chilikin, Andrey
> Sent: Saturday, November 15, 2014 12:57 AM
> To: Ananyev, Konstantin; Yerden Zhumabekov; Kamraan Nasim; dev@dpdk.org
> Cc: Yuanzhang Hu; Zhang, Helin
> Subject: RE: [dpdk-dev] Load-balancing position field in DPDK load_balancer
> sample app vs. Hash table
> 
> Fortville supports symmetrical hashing on HW level, a patch for i40e PMD was
> submitted a couple of weeks ago. For Niantic you can use symmetrical  rss key
> recommended by Konstantin.
> 
> Regards,
> Andrey
> 
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Friday, November 14, 2014 4:50 PM
> To: Yerden Zhumabekov; Kamraan Nasim; dev@dpdk.org
> Cc: Yuanzhang Hu
> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer
> sample app vs. Hash table
> 
> > -----Original Message-----
> > From: Yerden Zhumabekov [mailto:e_zhumabekov@sts.kz]
> > Sent: Friday, November 14, 2014 4:23 PM
> > To: Ananyev, Konstantin; Kamraan Nasim; dev@dpdk.org
> > Cc: Yuanzhang Hu
> > Subject: Re: [dpdk-dev] Load-balancing position field in DPDK
> > load_balancer sample app vs. Hash table
> >
> > I'd like to interject a question here.
> >
> > In case of flow classification, one might possibly prefer for packets
> > from the same flow to fall on the same logical core. With this '%'
> > load balancing, it would require to get the same RSS hash value for
> > packets with direct (src to dst) and swapped (dst to src) IPs and
> > ports. Am I correct that hardware RSS calculation cannot provide this
> symmetry?
> 
> As I remember, it is possible but you have to tweak rss key values.
> Here is a paper describing how to do that:
> http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf
> 
> Konstantin
> 
> >
> > 14.11.2014 20:44, Ananyev, Konstantin пишет:
> > > If you have a NIC that is capable to do HW hash computation, then
> > > you can do your load balancing based on that value.
> > > Let say ixgbe/igb/i40e NICs can calculate RSS hash value based on
> > > different combinations of dst/src Ips, dst/src ports.
> > > This value can be stored inside mbuf for each RX packet by PMD RX function.
> > > Then you can do:
> > > worker_id = mbuf->hash.rss % n_workersl
> > >
> > > That might to provide better balancing then using just one byte
> > > value, plus should be a bit faster, as in that case your balancer code don't
> need to touch packet's data.
> > >
> > > Konstantin
> >
> > --
> > Sincerely,
> >
> > Yerden Zhumabekov
> > State Technical Service
> > Astana, KZ
> >