From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: [RFC] Generic flow director/filtering/classification API Date: Wed, 20 Jul 2016 19:10:33 +0200 Message-ID: <20160720171033.GQ7621@6wind.com> References: <20160705181646.GO7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13DEA331@IRSMSX102.ger.corp.intel.com> <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> 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 , "Chilikin, Andrey" To: "Chandran, Sugesh" Return-path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 926B9532E for ; Wed, 20 Jul 2016 19:10:38 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id q128so64423654wma.1 for ; Wed, 20 Jul 2016 10:10:38 -0700 (PDT) Content-Disposition: inline In-Reply-To: <2EF2F5C0CC56984AA024D0B180335FCB13E05C5C@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, Please see below. On Wed, Jul 20, 2016 at 04:32:50PM +0000, Chandran, Sugesh wrote: [...] > > > How about a hardware flow flag in packet descriptor that set when t= he > > > packets hits any hardware rule. This way software doesn=E2=80=99t w= orry > > > /blocked by a hardware rule . Even though there is an additional > > > overhead of validating this flag, software datapath can identify th= e > > hardware processed packets easily. > > > This way the packets traverses the software fallback path until the > > > rule configuration is complete. This flag avoids setting ID action = for every > > hardware flow that are configuring. > >=20 > > That makes sense. I see it as a sort of single bit ID but it could be > > implemented through a different action for less capable devices. PMDs= that > > support 32 bit IDs could reuse the same code for both features. > >=20 > > I understand you'd prefer having this feature always present, however= we > > already know that not all PMDs/devices support it, and like everythin= g else > > this is a kind of offload that needs to be explicitly requested by th= e > > application as it may not be needed. > >=20 > > If we go with the separate action, then perhaps it would make sense t= o > > rename "ID" to "MARK" to make things clearer: > >=20 > > RTE_FLOW_ACTION_TYPE_FLAG /* Flag packets processed by flow rule. */ > >=20 > > RTE_FLOW_ACTION_TYPE_MARK /* Attach a 32 bit value to a packet. */ > >=20 > > I guess the result of the FLAG action would be something in ol_flag. > >=20 > [Sugesh] This looks fine for me. Great, I will update the specification accordingly. > > Thoughts? > >=20 > [Sugesh] Two more queries that I missed out in the earlier comments are= , > Support for PTYPE :- Intel NICs can report packet type in mbuf. > This can be used by software for the packet processing. Is generic API > capable of handling that as well?=20 Yes, however no PTYPE action has been defined for this (yet). It is only = a matter of adding one. Currently packet type recognition is enabled per port using a separate AP= I, so correct me if I'm wrong but I am not aware of any adapter with the ability to enable it per flow rule, so I do not think such an action need= s to be defined from the start. We may add it later. > RSS hashing support :- Just to confirm, the RSS flow action allows appl= ication > 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 ma= c or mac+ ip or=20 > 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 th= is flow rule. It is not performed on the device globally so packets which ar= e 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. Are we on the same page? --=20 Adrien Mazarguil 6WIND