Re: RFC: ethtool support for n-tuple filter programming

[Caitlin Bestler <caitlin.bestler@gmail.com>]

On Sat, Nov 7, 2009 at 3:28 PM, Rick Jones <rick.jones2@hp.com> wrote:
>
> At the risk of typing words into someone's keyboard, I interpreted it as
> suggesting using the filtering language of netfilter or something similar,
> not necessarily netfilter itself?
>

Correct, a netfilter-friendly interface to the driver could be invoked by
lower-overhead entities that netfilter and the driver would not care.

However the real goal would be to still use netfilter, which would become
a low-overhead entity if it could delegate 90% of the rules it enforced to
smart hardware.

The fundamental suggestion is to start with a filter specification that is
clearly too rich for any Ethernet device, and let the Ethernet devices
decide how quickly they want to catch up. As opposed to standardizing
how smart a smart Ethernet device is and potentially leaving some hardware
capabilities made inaccessible.

I'll point out that once you assume an Ethernet Device is capable of doing
TCP/UDP checksum offload and LSO/LRO then clearly you have recognized
that it is an L4 aware device. Designing its filtering rules as though it were
an L2-only device does not allow it to take advantage of the L4 parsing that
many/most Ethernet NICs already do.