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

[Wu, Jingjing]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, February 26, 2016 2:25 AM
> To: Rahul Lakkireddy <rahul.lakkireddy at chelsio.com>
> Cc: Richardson, Bruce <bruce.richardson at intel.com>; dev at dpdk.org; Kumar A S
> <kumaras at chelsio.com>; Nirranjan Kirubaharan <nirranjan at chelsio.com>; Wu, Jingjing
> <jingjing.wu at intel.com>
> Subject: Re: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch
> to fdir
> 
> 2016-02-25 15:03, Rahul Lakkireddy:
> > On Wednesday, February 02/24/16, 2016 at 14:17:58 -0800, Thomas Monjalon wrote:
> > > > A raw flow provides a generic way for vendors to add their vendor
> > > > specific input flow.
> > >
> > > Please, "generic" and "vendor specific" in the same sentence.
> > > It's obviously wrong.
> >
> > I think this sentence is being mis-interpreted.
> > What I intended to say is: the fields are generic so that any vendor can
> > hook-in. The fields themselves are not vendor specific.
> 
> We are trying to push some features into fields of an API instead of
> thinking how to make it simple.
> 
> > > > 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?
> 
Hi Thomas

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.

No matter chelsio NIC filter uses flow director API or define another new filter type. I vote
the change happened in struct rte_eth_fdir_input, it provide a RAW Flow type,
And there is also a mask field for that, by this way, user can have a flexible way to configure.
And drivers can parse the raw input to define the filter fields.

But for the change happened in struct rte_eth_fdir_action, only SWITCH type is added,
Where to switch? All things is in behavior_arg[RTE_ETH_BEHAVIOR_ARG_MAX_LEN]
which is black to user. Maybe your previous define in RFC makes more sense. It's better to add
user defined field but not for all args.

Any better suggestion?