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:

quoted

2016-02-24 14:43, Bruce Richardson:

quoted

On Wed, Feb 03, 2016 at 02:02:22PM +0530, Rahul Lakkireddy wrote:

quoted

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.

quoted

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.