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

Matt Laswell laswell at infiniteio.com
Sat Nov 15 16:28:01 CET 2014


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 <e_zhumabekov at 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 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
>
>


More information about the dev mailing list