Hi Adrien, Thanks so much for the explanation.
> -----Original Message----- > From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com] > Sent: Friday, July 08, 2016 9:26 PM > To: Liang, Cunming <cunming.liang 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> > Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification > API > > Hi Cunming, > > I agree with Bruce, I'll start snipping non relevant parts considering the > size of this message. Please see below. > > On Fri, Jul 08, 2016 at 07:11:28PM +0800, Liang, Cunming wrote: > [...] > > >Meta item types > > >~~~~~~~~~~~~~~~ > > > > > >These do not match packet data but affect how the pattern is processed, > > >most > > >of them do not need a specification structure. This particularity allows > > >them to be specified anywhere without affecting other item types. > > [LC] For the meta item(END, VOID, INVERT) and some data matching type like > > ANY and RAW, > > it's all PMD responsible to understand the key character and to parse the > > header graph? > > We haven't started on the PMD side of things yet (the public API described > here does not discuss it), but I think PMDs will see the pattern as-is, > untranslated (to answer your question, yes, it will be the case for END, > VOID, INVERT, ANY and RAW like all others). > > However I intend to add private helper functions as needed in librte_ether > (or anywhere else in EAL) that PMDs can call to ease parsing and validation > of flow rules, otherwise most of them will end up implementing redundant > functions. [LC] Agree, that's very helpful. > > [...] > > >When several actions are combined in a flow rule, they should all have > > >different types (e.g. dropping a packet twice is not possible). However > > >considering the VOID type is an exception to this rule, the defined > > >behavior > > >is for PMDs to only take into account the last action of a given type found > > >in the list. PMDs still perform error checking on the entire list. > > > > > >*Note that PASSTHRU is the only action able to override a terminating > > >rule.* > > [LC] I'm wondering how to address the meta data carried by mbuf, there's no > > mentioned here. > > For packets hit one specific flow, usually there's something for CPU to > > identify the flow. > > FDIR and RSS as an example, has id or key in mbuf. In addition, some meta > > may pointed by userdata in mbuf. > > Any view on it ? > > Yes, this is defined as the ID action. It is described in 4.1.6.4 (ID) and > there is an example how a FDIR rule would be converted to use it in 5.7 > (FDIR to most item types ? QUEUE, DROP, PASSTHRU). [LC] So in RSS cases, the actions would be {RSS, ID}, in which ID represent for RSS key, right? > > It is basically described as a flow rule with two actions: queue redirection > and packet tagging. > > Does it answer your question? [LC] I think so, Thanks. > > -- > Adrien Mazarguil > 6WIND