From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: [RFC] Generic flow director/filtering/classification API Date: Fri, 8 Jul 2016 15:25:44 +0200 Message-ID: <20160708132544.GE7621@6wind.com> References: <20160705181646.GO7621@6wind.com> <577F8A60.2000409@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org, Thomas Monjalon , Helin Zhang , Jingjing Wu , Rasesh Mody , Ajit Khaparde , Rahul Lakkireddy , Wenzhuo Lu , Jan Medala , John Daley , Jing Chen , Konstantin Ananyev , Matej Vido , Alejandro Lucero , Sony Chacko , Jerin Jacob , Pablo de Lara , Olga Shern To: "Liang, Cunming" 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 1531D6CA2 for ; Fri, 8 Jul 2016 15:25:49 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id n127so12930204wme.1 for ; Fri, 08 Jul 2016 06:25:49 -0700 (PDT) Content-Disposition: inline In-Reply-To: <577F8A60.2000409@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 Cunming, I agree with Bruce, I'll start snipping non relevant parts considering th= e 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 allo= ws > >them to be specified anywhere without affecting other item types. > [LC] For the meta item(END, VOID, INVERT) and some data matching type l= ike > ANY and RAW, > it's all PMD responsible to understand the key character and to parse t= he > header graph? We haven't started on the PMD side of things yet (the public API describe= d 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_ethe= r (or anywhere else in EAL) that PMDs can call to ease parsing and validati= on of flow rules, otherwise most of them will end up implementing redundant functions. [...] > >When several actions are combined in a flow rule, they should all have > >different types (e.g. dropping a packet twice is not possible). Howeve= r > >considering the VOID type is an exception to this rule, the defined be= havior > >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 me= ta > 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) an= d there is an example how a FDIR rule would be converted to use it in 5.7 (FDIR to most item types =E2=86=92 QUEUE, DROP, PASSTHRU). It is basically described as a flow rule with two actions: queue redirect= ion and packet tagging. Does it answer your question? --=20 Adrien Mazarguil 6WIND