From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet Subject: Re: [RFC 17.08] flow_classify: add librte_flow_classify library Date: Fri, 19 May 2017 11:11:27 +0200 Message-ID: <20170519091127.GY14914@bidouze.vm.6wind.com> References: <20170420185448.19162-1-ferruh.yigit@intel.com> <20170517163848.GQ14914@bidouze.vm.6wind.com> <2028578.MMgbIyi7hy@xps> <2601191342CEEE43887BDE71AB9772583FAF803F@IRSMSX109.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Thomas Monjalon , "Yigit, Ferruh" , "dev@dpdk.org" , "Mcnamara, John" , "Tahhan, Maryam" , "adrien.mazarguil@6wind.com" To: "Ananyev, Konstantin" 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 831362C5 for ; Fri, 19 May 2017 11:11:34 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id d127so79607392wmf.0 for ; Fri, 19 May 2017 02:11:34 -0700 (PDT) Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772583FAF803F@IRSMSX109.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, May 19, 2017 at 08:57:01AM +0000, Ananyev, Konstantin wrote: > > >> -----Original Message----- >> From: Thomas Monjalon [mailto:thomas@monjalon.net] >> Sent: Thursday, May 18, 2017 9:32 PM >> To: Yigit, Ferruh >> Cc: dev@dpdk.org; Gaëtan Rivet ; Ananyev, Konstantin ; Mcnamara, John >> ; Tahhan, Maryam ; adrien.mazarguil@6wind.com >> Subject: Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library >> >> 18/05/2017 13:33, Ferruh Yigit: >> > On 5/17/2017 5:38 PM, Gaëtan Rivet wrote: >> > > The other is the expression of flows through a shared syntax. Using >> > > flags to propose presets can be simpler, but will probably not be flexible >> > > enough. rte_flow_items are a first-class citizen in DPDK and are >> > > already a data type that can express flows with flexibility. As >> > > mentioned, they are however missing a few elements to fully cover IPFIX >> > > meters, but nothing that cannot be added I think. >> > > >> > > So I was probably not clear enough, but I was thinking about >> > > supporting rte_flow_items in rte_flow_classify as the possible key >> > > applications would use to configure their measurements. This should not >> > > require rte_flow supports from the PMDs they would be using, only >> > > rte_flow_item parsing from the rte_flow_classify library. >> > > >> > > Otherwise, DPDK will probably end up with two competing flow >> > > representations. Additionally, it may be interesting for applications >> > > to bind these data directly to rte_flow actions once the >> > > classification has been analyzed. >> > >> > Thanks for clarification, I see now what you and Konstantin is proposing. >> > >> > And yes it makes sense to use rte_flow to define flows in the library, I >> > will update the RFC. >> >> Does it mean that rte_flow.h must be moved from ethdev to this >> new flow library? Or will it depend of ethdev? Even outside of lib/librte_ether, wouldn't rte_flow stay dependent on rte_ether? > >Just a thought: probably move rte_flow.h to lib/librte_net? >Konstantin If we are to move rte_flow, why not lib/librte_flow? -- Gaëtan Rivet 6WIND