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?
