2016-02-26 01:17, Wu, Jingjing:
> From: Thomas Monjalon [mailto:thomas.monjalon at 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?
