Subject: Re: [patch net-next v2 8/9] switchdev: introduce Netlink API

From: John Fastabend <[email-masked]>
Date: Mon, 22 Sep 2014 18:36:44 -0700

On 09/22/2014 04:07 PM, Tom Herbert wrote:
> On Mon, Sep 22, 2014 at 3:53 PM, Thomas Graf <[email-masked]> wrote:
>> On 09/22/14 at 03:40pm, Tom Herbert wrote:
>>> On Mon, Sep 22, 2014 at 3:17 PM, Thomas Graf <[email-masked]> wrote:
>>>> What makes stateful offload interesting to me is that the final
>>>> desintation of a packet is known at RX and can be redirected to a
>>>> queue or VF. This allows to build packet batches on shared pages
>>>> while preserving the securiy model.
>>>>
>>> How is this different from what rx-filtering already does?
>>
>> Without stateful offload I can't know where the packet is destined
>> to until after I've allocated an skb and parsed the packet in
>> software. I might be missing what you refer to here specifically.
>
> n-tuple filtering in as exposed by ethtool.

n-tuple has some deficiencies,

	- its not possible to get the capabilities to learn what
	  fields are supported by the device, what actions, etc.

	- its ioctl based so we have to poll the device

	- only supports a single table, where we have devices with
	  multiple tables

	- sort of the same as above but it doesn't allow creating new
	  tables or destroying old tables.

I probably missed a few others but those are the main ones that I
would like to address. Granted other than the ioctl line the rest could
be solved by extending the existing interface. However I would just
assume port it to ndo_ops and netlink then extend the existing ioctl
seeing it needs a reasonable overall to support the above anyways.

We could port the ethtool ops over to the new interface to
simplify drivers.

.John

-- 
John Fastabend         Intel Corporation