[dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library

[Ananyev, Konstantin]

> -----Original Message-----
> From: Gaëtan Rivet [mailto:gaetan.rivet at 6wind.com]
> Sent: Friday, May 19, 2017 10:11 AM
> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Cc: Thomas Monjalon <thomas at monjalon.net>; Yigit, Ferruh <ferruh.yigit at intel.com>; dev at dpdk.org; Mcnamara, John
> <john.mcnamara at intel.com>; Tahhan, Maryam <maryam.tahhan at intel.com>; adrien.mazarguil at 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:thomas at monjalon.net]
> >> Sent: Thursday, May 18, 2017 9:32 PM
> >> To: Yigit, Ferruh <ferruh.yigit at intel.com>
> >> Cc: dev at dpdk.org; Gaëtan Rivet <gaetan.rivet at 6wind.com>; Ananyev, Konstantin <konstantin.ananyev at intel.com>; Mcnamara, John
> >> <john.mcnamara at intel.com>; Tahhan, Maryam <maryam.tahhan at intel.com>; adrien.mazarguil at 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