From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: [RFC] Generic flow director/filtering/classification API Date: Thu, 21 Jul 2016 15:37:09 +0200 Message-ID: <20160721133709.GS7621@6wind.com> References: <20160708130310.GD7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13DEB236@IRSMSX102.ger.corp.intel.com> <20160713200327.GC7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13DEE55F@IRSMSX102.ger.corp.intel.com> <20160715150402.GE7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13E02938@IRSMSX102.ger.corp.intel.com> <20160718150029.GJ7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13E05C5C@IRSMSX102.ger.corp.intel.com> <20160720171033.GQ7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13E062E8@IRSMSX102.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "dev@dpdk.org" , Thomas Monjalon , "Zhang, Helin" , "Wu, Jingjing" , Rasesh Mody , Ajit Khaparde , Rahul Lakkireddy , "Lu, Wenzhuo" , Jan Medala , John Daley , "Chen, Jing D" , "Ananyev, Konstantin" , Matej Vido , Alejandro Lucero , Sony Chacko , Jerin Jacob , "De Lara Guarch, Pablo" , Olga Shern , "Chilikin, Andrey" To: "Chandran, Sugesh" Return-path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id AF3C847CD for ; Thu, 21 Jul 2016 15:37:16 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id i5so25681269wmg.0 for ; Thu, 21 Jul 2016 06:37:16 -0700 (PDT) Content-Disposition: inline In-Reply-To: <2EF2F5C0CC56984AA024D0B180335FCB13E062E8@IRSMSX102.ger.corp.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Sugesh, I do not have much to add, please see below. On Thu, Jul 21, 2016 at 11:06:52AM +0000, Chandran, Sugesh wrote: [...] > > > RSS hashing support :- Just to confirm, the RSS flow action allows > > > application to decide the header fields to produce the hash. This > > > gives programmability on load sharing across different queues. The > > > application can program the NIC to calculate the RSS hash only using > > > mac or mac+ ip or ip only using this. > > > > I'd say yes but from your summary, I'm not sure we share the same idea of > > what the RSS action is supposed to do, so here is mine. > > > > Like all flow rules, the pattern part of the RSS action only filters the packets > > on which the action will be performed. > > > > The rss_conf parameter (struct rte_eth_rss_conf) only provides a key and a > > RSS hash function to use (ETH_RSS_IPV4, ETH_RSS_NONFRAG_IPV6_UDP, > > etc). > > > > Nothing prevents the RSS hash function from being applied to protocol > > headers which are not necessarily present in the flow rule pattern. These are > > two independent things, e.g. you could have a pattern matching IPv4 packets > > yet perform RSS hashing only on UDP headers. > > > > Finally, the RSS action configuration only affects packets coming from this > > flow rule. It is not performed on the device globally so packets which are not > > matched are not affected by RSS processing. As a result it might not be > > possible to configure two flow rules specifying incompatible RSS actions > > simultaneously if the underlying device supports only a single global RSS > > context. > > > [Sugesh] thank you for the explanation. This means I can have a rule that matches on > Every incoming packets(all field wild card rule) and does RSS hash on selected fields, > MAC only, IP only or IP & MAC? Yes, I guess it could even replace the current method for configuring RSS on a device in a more versatile fashion, but this is a topic for another debate. Let's implement this API first! > This can be useful to do a packet lookup in software by just using > Only hash. Not sure to fully understand your idea, but I'm positive it could be done somehow :) -- Adrien Mazarguil 6WIND