So, what are the requirements? The hardware already parses L2, L3, L4 headers,
and for the future generation we could add to the set of already supported
steering/filtering criteria. Having some discussion on the essential vs.
optional requirements seems like the right thing at this point.
On one hand, this describes what's available:
http://www.spinics.net/lists/netdev/msg04001.html
OTOH, and this is just my opinion - it'd be unrealistic to expect a general
purpose NIC to offload the entire netfilter. On the third hand, one could
think of IPsec and/or NAT, and what happens then with the hardware-supported
filtering. And so on.
There's also a question of relative importance specifically for the Data
Center environment.
Anyway, discussion would help.
Caitlin Bestler wrote:
David S. Miller wrote:
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Wed, 3 May 2006 22:07:40 +0400
On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
([EMAIL PROTECTED]) wrote:
I'd expect high end NIC ASICs to implement rx steering based upon
some sort of hash (for load balancing), as well as explicit "1:1"
steering between a sw channel and a hw channel. Both options for
channel configuration are present in the driver interface.
If netfilter assists can be done in hardware, I agree the driver
interface will need to add support for these - otherwise,
netfilter processing will stay above the driver.
Even if the hardware cannot fully implement netfilter rules there is
still value in having an interface that documents exactly how much
filtering a given piece of hardware can do.
There is no point in having the kernel repeat packet classifications
that have already been done by the NIC.
Please do not suppose that vj channel must rely on underlaying
hardware.
I am not. I am just saying that it is futile to build
hardware that cannot handle netfilter at least to some
extent, because this will result in HW net channels being
disabled for %99 of real users which makes the hardware just a waste.
Or netfilters being disabled, which would be just as bad or worse.
The kernel and hardware need to co-operate so that users are not
asked to make artificial choices between performance and security.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
