[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
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_zhumabe...@sts.kz] Sent: Friday, November 14, 2014 5:21 PM To: Chilikin, Andrey; Ananyev, Konstantin; Kamraan Nasim; dev at 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 at dpdk.org] On Behalf Of Ananyev, > Konstantin > Sent: Friday, November 14, 2014 4:50 PM > To: Yerden Zhumabekov; Kamraan Nasim; dev at 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 at sts.kz] >> Sent: Friday, November 14, 2014 4:23 PM >> To: Ananyev, Konstantin; Kamraan Nasim; dev at 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
[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
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 at 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 at dpdk.org] On Behalf Of Ananyev, Konstantin > Sent: Friday, November 14, 2014 4:50 PM > To: Yerden Zhumabekov; Kamraan Nasim; dev at 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 at sts.kz] > > Sent: Friday, November 14, 2014 4:23 PM > > To: Ananyev, Konstantin; Kamraan Nasim; dev at 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 > >
[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
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 at infiniteio.com <mailto:laswell at infiniteio.com>
> infinite io, inc.
>
> On Fri, Nov 14, 2014 at 10:57 AM, Chilikin, Andrey
> mailto:andrey.chilikin at 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 at dpdk.org
> <mailto:dev-bounces at dpdk.org>] On Behalf Of Ananyev, Konstantin
> Sent: Friday, November 14, 2014 4:50 PM
> To: Yerden Zhumabekov; Kamraan Nasim; dev at dpdk.org
> <mailto:dev at 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 at sts.kz
> <mailto:e_zhumabekov at sts.kz>]
> > Sent: Friday, November 14, 2014 4:23 PM
> > To: Ananyev, Konstantin; Kamraan Nasim; dev at dpdk.org
> <mailto:dev at 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
[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
Fantastic. Thanks for the assist.
--
Matt Laswell
laswell at infiniteio.com
infinite io, inc.
On Sat, Nov 15, 2014 at 1:10 AM, Yerden Zhumabekov
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 at infiniteio.com
> infinite io, inc.
>
> On Fri, Nov 14, 2014 at 10:57 AM, Chilikin, Andrey <
> andrey.chilikin at 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 at dpdk.org] On Behalf Of Ananyev, Konstantin
>> Sent: Friday, November 14, 2014 4:50 PM
>> To: Yerden Zhumabekov; Kamraan Nasim; dev at 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 at sts.kz]
>> > Sent: Friday, November 14, 2014 4:23 PM
>> > To: Ananyev, Konstantin; Kamraan Nasim; dev at 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
>
>
[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 at dpdk.org] On Behalf Of Ananyev, Konstantin > Sent: Friday, November 14, 2014 4:50 PM > To: Yerden Zhumabekov; Kamraan Nasim; dev at 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 at sts.kz] >> Sent: Friday, November 14, 2014 4:23 PM >> To: Ananyev, Konstantin; Kamraan Nasim; dev at 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
[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
14.11.2014 22:50, Ananyev, Konstantin ?: >> -Original Message- >> From: Yerden Zhumabekov [mailto:e_zhumabekov at sts.kz] >> Sent: Friday, November 14, 2014 4:23 PM >> To: Ananyev, Konstantin; Kamraan Nasim; dev at 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
[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? 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
[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-boun...@dpdk.org] On Behalf Of Ananyev, Konstantin Sent: Friday, November 14, 2014 4:50 PM To: Yerden Zhumabekov; Kamraan Nasim; dev at 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 at sts.kz] > Sent: Friday, November 14, 2014 4:23 PM > To: Ananyev, Konstantin; Kamraan Nasim; dev at 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 >
[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
> -Original Message- > From: Yerden Zhumabekov [mailto:e_zhumabekov at sts.kz] > Sent: Friday, November 14, 2014 4:23 PM > To: Ananyev, Konstantin; Kamraan Nasim; dev at 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 >
[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Kamraan Nasim > Sent: Thursday, November 13, 2014 6:30 PM > To: dev at 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
[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
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 at infiniteio.com infinite io, inc. On Fri, Nov 14, 2014 at 10:57 AM, Chilikin, Andrey < andrey.chilikin at 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 at dpdk.org] On Behalf Of Ananyev, Konstantin > Sent: Friday, November 14, 2014 4:50 PM > To: Yerden Zhumabekov; Kamraan Nasim; dev at 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 at sts.kz] > > Sent: Friday, November 14, 2014 4:23 PM > > To: Ananyev, Konstantin; Kamraan Nasim; dev at 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 > > > >
[dpdk-dev] Load-balancing position field in DPDK load_balancer sample app vs. Hash table
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
[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? --Kam
