Re: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2016-02-26 01:17, Wu, Jingjing:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-02-25 15:03, Rahul Lakkireddy:
> > > On Wednesday, February 02/24/16, 2016 at 14:17:58 -0800, Thomas Monjalon wrote:
> > > > > In our case, it is possible to match several flows
> > > > > in a single rule.  For example, it's possible to set an ethernet, vlan,
> > > > > ip and tcp/udp flows all in a single rule.  We can specify all of these
> > > > > flows in a single raw input flow, which can then be passed to cxgbe flow
> > > > > director to set the corresponding filter.
> > > >
> > > > I feel we need to define what is an API.
> > > > If the application wants to call something specific to the NIC, why using
> > > > the ethdev API? You just have to include cxgbe.h.
> > >
> > > Well, in that sense, flow-director is also very intel specific, no ?
> > 
> > Yes. I think the term "flow director" comes from Intel.
> > 
> > > What we are trying to do is make flow-director generic
> > 
> > So let's stop calling it flow director.
> > We are talking about filtering, right?
> 
> Are you suggesting chelsio to define a new filter type?
> 
> > Why is it so complex? We are talking about packet filtering, not rocket science!
> >
> The complex is due to different NICs different behavior :-)
> As I know, it is a common way to use used-define data pass specific infor to driver.
> 
> Even flow director is concept from Intel's NIC, but I think it is the generic one comparing
> with other kinds of filters. So I think that's why Rahul choose it to add their kind of filters.
> As I know enic driver also uses flow director API to support their filters.
[...]
> Any better suggestion?

We have a more generic proposal now:
	http://dpdk.org/ml/archives/dev/2016-July/043365.html
Rahul, does it fit your needs?