|| ||"David S. Miller" <davem-AT-davemloft.net>|
|| ||Re: [PATCH] TCP Offload (TOE) - Chelsio|
|| ||Thu, 18 Aug 2005 16:02:25 -0700 (PDT)|
|| ||jgarzik-AT-pobox.com, sbardone-AT-chelsio.com, netdev-AT-vger.kernel.org,
From: Timur Tabi <firstname.lastname@example.org>
Date: Thu, 18 Aug 2005 17:45:13 -0500
> I think a more accurate question would be, "what TCP/IP stack am I
> talking to, today?" You're making it sound as if TOE fundamentally
> changes the entire Linux kernel, when it only affects networking.
Networking is arguably about half of the kernel, and Linux is
pretty useless for most folks without networking.
The point remains that TOE creates an ENORMOUS support burdon
upon us, and makes bugs harder to field even if we add the
"TOE Taint" thing.
You say what users will expect, and that they will understand, but
history in other areas shows that they simply don't. Even after
clicking the license agreement et al. on the NVIDIA web site when
downloading their binary-only graphics drivers for Linux, people STILL
REPORT crashes to linux-kernel and various distribution vendors with
that driver loaded.
Think people won't report bugs caused by TOE here? Think again...
It's a huge problem, and many man hours are wasted on this.
The next issue is when customers ask "Well I paid $500 for this TOE
card, how come I can't do netfilter or traffic classification?". And
they will ask distribution vendors and places like the linux-kernel
and netdev mailing lists these questions, creating a further burdon
Finally, even ignoring all of that, the argument for stack
maintainability is still there. TOE puts it's hooks deep into
the networking stack, and that in and of itself is a long-term
I am still very much against TOE going into the Linux networking
stack. There are ways to obtain TOE's performance without
necessitating stateful support in the cards, everything that's
worthwhile can be done with stateless offloads.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)