Jeff Garzik wrote:
1) RFC compliance differs based on whether you use a TOE NIC, or Linux
software stack. "What Linux am I talking to, today?"
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.
The concept is very similar to after-market auto parts. If I replace the intercooler in
my Audi S4, would you expect me to care if Audi said, "But your car's cooling system won't
work like it used to!" Of course not. Similarly, if I purchased a $500 TOE-capable
network adapter and compiled my kernel with TOE support, I'm not going to expect the
kernel developers to address any problems.
The whole point behind TOE is that you use a different TCP/IP stack. The only meaningful
alternative would be to copy the kernel code into the adapter, and have the adapter's
processor run that code. It would be a sort of "1.5-way SMP" system. Maybe in the future
there will be SMP systems that have CPUs dedicated to different I/O devices, but until
then we need something like TOE to handle 10Gb Ethernet.
I don't think TOE is unreasonable. If the user enables a TOE device on his system, he
should be aware that he's now using a different TCP/IP stack. You can add a "network
stack taint" flag if TOE is ever enabled.
About the only TOE situation I could imagine which -would- would be
where the TOE firmware source code is included in the Linux kernel
source code, but even then, all the hooks would be nasty.
What if that source code can't be compiled by gcc? What if it uses a proprietary
compiler, perhaps one that doesn't even run on Linux?
--
Timur Tabi
Staff Software Engineer
[EMAIL PROTECTED]
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
-- Ed Smylie, NASA engineer for Apollo 13
-
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
