From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: [RFC] Generic flow director/filtering/classification API Date: Mon, 11 Jul 2016 12:06:22 +0200 Message-ID: <20160711100621.GJ7621@6wind.com> References: <20160705181646.GO7621@6wind.com> <577F8A60.2000409@intel.com> <20160708132544.GE7621@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 To: "Liang, Cunming" Return-path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id DB2632BA1 for ; Mon, 11 Jul 2016 12:06:26 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id i5so9104317wmg.0 for ; Mon, 11 Jul 2016 03:06:26 -0700 (PDT) Content-Disposition: inline In-Reply-To: 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" On Mon, Jul 11, 2016 at 03:18:19AM +0000, Liang, Cunming wrote: [...] > > > >When several actions are combined in a flow rule, they should all = have > > > >different types (e.g. dropping a packet twice is not possible). Ho= wever > > > >considering the VOID type is an exception to this rule, the define= d behavior > > > >is for PMDs to only take into account the last action of a given t= ype found > > > >in the list. PMDs still perform error checking on the entire list. > > > > > > > >*Note that PASSTHRU is the only action able to override a terminat= ing rule.* > > > [LC] I'm wondering how to address the meta data carried by mbuf, th= ere's no > > > mentioned here. > > > For packets hit one specific flow, usually there's something for CP= U to > > > identify the flow. > > > FDIR and RSS as an example, has id or key in mbuf. In addition, som= e meta > > > may pointed by userdata in mbuf. > > > Any view on it ? > >=20 > > 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 =E2=86=92 QUEUE, DROP, PASSTHRU). > [LC] So in RSS cases, the actions would be {RSS, ID}, in which ID repre= sent for RSS key, right? Well, the ID action is always the same regardless of other actions, it takes an arbitrary 32 bit value to be returned back as meta data with matched packets, no side effect on RSS is expected. If you are talking about the RSS action (4.1.6.9), RSS configuration (key and algorithm to use) are provided in their specific structure along with the list of target queues (see struct rte_flow_action_rss in [1]). Note the RSS action is independent, it is unrelated to the port-wide RSS configuration. Devices may not be able to support both simultaneously, fo= r instance creating multiple queues with RSS enabled globally may prevent requesting a flow rule with a RSS action later. Likewise, such a rule may possibly be defined only once depending on capabilities. For devices supporting both, think of it as multiple level RSS. Flow rule= s perform RSS on selected packets first, then the default global RSS configuration takes care of packets that haven't hit a terminating flow rule. This is the same as the QUEUE action except RSS is additionally performed to spread packet among several queues. Thus applications can request RSS with ID to get both RSS _and_ their arbitrary 32 bit value as meta data. Once again, HW support for this combination is not mandatory. PMDs can assist HW to work around such limitations sometimes as described= in 4.4.4 (Unsupported actions) as long as the software cost is kept minimal. [1] https://raw.githubusercontent.com/6WIND/rte_flow/master/rte_flow.h --=20 Adrien Mazarguil 6WIND