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?

--
Gaëtan Rivet
6WIND

Reply via email to