On 09/22/2014 04:07 PM, Tom Herbert wrote:
On Mon, Sep 22, 2014 at 3:53 PM, Thomas Graf <tg...@suug.ch> wrote:
On 09/22/14 at 03:40pm, Tom Herbert wrote:
On Mon, Sep 22, 2014 at 3:17 PM, Thomas Graf <tg...@suug.ch> 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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
