HI Adrien, Thank you for your effort and considering the inputs and comments. The design looks fine for me now.
Regards _Sugesh > -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com] > Sent: Thursday, July 21, 2016 2:37 PM > To: Chandran, Sugesh <sugesh.chandran at intel.com> > Cc: dev at dpdk.org; Thomas Monjalon <thomas.monjalon at 6wind.com>; > Zhang, Helin <helin.zhang at intel.com>; Wu, Jingjing > <jingjing.wu at intel.com>; Rasesh Mody <rasesh.mody at qlogic.com>; Ajit > Khaparde <ajit.khaparde at broadcom.com>; Rahul Lakkireddy > <rahul.lakkireddy at chelsio.com>; Lu, Wenzhuo <wenzhuo.lu at intel.com>; > Jan Medala <jan at semihalf.com>; John Daley <johndale at cisco.com>; Chen, > Jing D <jing.d.chen at intel.com>; Ananyev, Konstantin > <konstantin.ananyev at intel.com>; Matej Vido <matejvido at gmail.com>; > Alejandro Lucero <alejandro.lucero at netronome.com>; Sony Chacko > <sony.chacko at qlogic.com>; Jerin Jacob > <jerin.jacob at caviumnetworks.com>; De Lara Guarch, Pablo > <pablo.de.lara.guarch at intel.com>; Olga Shern <olgas at mellanox.com>; > Chilikin, Andrey <andrey.chilikin at intel.com> > Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification > API > > 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
