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

[Thomas Monjalon]

Caution: I truly respect the work done by Chelsio on DPDK.
And I'm sure you can help to build a good filtering API, which
was mainly designed with Intel needs in mind because it was
difficult to have opinions of other vendors some time ago.
That's why it's a chance to have new needs and it would be a shame
to let it go through a vendor specific backdoor.

2016-02-25 00:10, Rahul Lakkireddy:
> Hi Thomas,
> 
> On Wednesday, February 02/24/16, 2016 at 07:02:42 -0800, Thomas Monjalon wrote:
> > 2016-02-24 14:43, Bruce Richardson:
> > > On Wed, Feb 03, 2016 at 02:02:22PM +0530, Rahul Lakkireddy wrote:
> > > > Add a new raw packet flow that allows specifying generic flow input.
> > > > 
> > > > Add the ability to provide masks for fields in flow to allow range of
> > > > values.
> > > > 
> > > > Add a new behavior switch.
> > > > 
> > > > Add the ability to provide behavior arguments to allow rewriting matched
> > > > fields with new values. Ex: allows to provide new ip and port addresses
> > > > to rewrite the fields of packets matching a filter rule before NAT'ing.
> > > > 
> > > Thomas, any comments as ethdev maintainer?
> > 
> > Yes, some comments.
> > First, there are several different changes in the same patch. It must be split.
> 
> Should each structure change be split into a separate patch?

A patch = a feature.
The switch action and the flow rule are different things.

> > Then I don't understand at all the raw flow filter. What is a raw flow?
> > How behavior_arg must be used?
> 
> This was discussed with Jingjing at
> 
> http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/31471

Thanks, I missed it.

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

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

> On similar lines, behavior_arg provides a generic way to pass extra
> action arguments for matched flows.  For example, in our case, to
> perform NAT, the new src/dst ip and src/dst port addresses to be
> re-written for a matched rule can be passed in behavior_arg.

Yes a kind of void* to give what you want to the driver without the
convenience of a documented function.

I know the support of filters among NICs is really heterogeneous.
And the DPDK API are not yet generic enough. But please do not give up!
If the filtering API can be improved to support your cases, please do it.