From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yerden Zhumabekov Subject: Re: Load-balancing position field in DPDK load_balancer sample app vs. Hash table Date: Fri, 14 Nov 2014 22:23:00 +0600 Message-ID: <54662C64.9040500@sts.kz> References: <2601191342CEEE43887BDE71AB977258213ADDFA@IRSMSX105.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: Yuanzhang Hu To: "Ananyev, Konstantin" , Kamraan Nasim , "dev-VfR2kkLFssw@public.gmane.org" Return-path: In-Reply-To: <2601191342CEEE43887BDE71AB977258213ADDFA-kPTMFJFq+rEu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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 =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > 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 diffe= rent combinations of=20 > dst/src Ips, dst/src ports. > This value can be stored inside mbuf for each RX packet by PMD RX funct= ion. > Then you can do: > worker_id =3D 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 n= eed to touch packet's data. =20 > > Konstantin --=20 Sincerely, Yerden Zhumabekov State Technical Service Astana, KZ