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. 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
