> -----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?
