> -----Original Message----- > From: Gaëtan Rivet [mailto:gaetan.ri...@6wind.com] > Sent: Friday, May 19, 2017 10:11 AM > To: Ananyev, Konstantin <konstantin.anan...@intel.com> > Cc: Thomas Monjalon <tho...@monjalon.net>; Yigit, Ferruh > <ferruh.yi...@intel.com>; dev@dpdk.org; Mcnamara, John > <john.mcnam...@intel.com>; Tahhan, Maryam <maryam.tah...@intel.com>; > adrien.mazarg...@6wind.com > Subject: Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify > library > > On Fri, May 19, 2017 at 08:57:01AM +0000, Ananyev, Konstantin wrote: > > > > > >> -----Original Message----- > >> From: Thomas Monjalon [mailto:tho...@monjalon.net] > >> Sent: Thursday, May 18, 2017 9:32 PM > >> To: Yigit, Ferruh <ferruh.yi...@intel.com> > >> Cc: dev@dpdk.org; Gaëtan Rivet <gaetan.ri...@6wind.com>; Ananyev, > >> Konstantin <konstantin.anan...@intel.com>; Mcnamara, John > >> <john.mcnam...@intel.com>; Tahhan, Maryam <maryam.tah...@intel.com>; > >> adrien.mazarg...@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?
To avoid new dependency for lib/lirte_ethdev? > > -- > Gaëtan Rivet > 6WIND
