On 8/12/05, Mitchell Blank Jr <[EMAIL PROTECTED]> wrote:

> I'm fairly pessimistic about full TOE also, I just want to see the patch
> cleaned up a bit so we can see the exact impact it would have.  The RX
> optimization work presented in the Neterion and Intel papers at OLS sounds a
> lot more interesting to me though.
> 
> However, I do want to comment on one statement of yours:
> 
> Jeff Garzik wrote:
> > 3) Netfilter.  Either a TOE NIC (a) doesn't support netfilter, (b) needs
> > far-reaching packet mangling hooks, or (c) includes its own custom
> > netfilter [clone], with attendant bugs and maintenance issues.
> 
> I don't think netfilter is a big deal.  The kernel could still check the
> TCP handshake packets (or, if needed, faked-up versions with the same data)
> at accept()/connect() time.  If those pass muster it's a pretty good bet
> that the other 100,000 packets making up that TCP connection would also.
> Of course this limitation would need to be documented but I doubt most
> netfilter users would mind too much.  There's obviously edge cases where
> you can lose like if you update the netfilter rules you ideally want to
> revalidate all the currently open connections.

This is true.  There is nothing fundamentally preventing both passive
and active opens to check netfilter before OKing a connection.  Once a
connection is established, it's rather impractical to run each of its
packets through netfilter, this is 10G after all.  You'd probably not
lose much functionality that you could have otherwise used at these
speeds.

Also, TOEs don't hijack connections from the SW stack.  If the SW
stack feels that a connection requires facilities that only it can
offer all it has to do is not offload it.

> Since TOE hardware is designed to help the TCP end point you probably
> don't have to worry about NAT or other fancy mangling on these interfaces.
> 
> -Mitch
> 
> 
> 
>
-
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

Reply via email to