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

["Chilikin, Andrey" <andrey.chilikin@intel.com>]

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
>