On Thu, 18 Aug 2005, David S. Miller wrote: > 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.
Simply switch off the TOE to see if its TOE or the OS stack. TCP is fairly standard though this is a pretty rare case. > 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. Crashes in the opensource TOE layer or the opensource TOE drivers will certainly need to be report to linux-kernel. > 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 developer community will also increase since the vendors have typically folks on the mailing list to help with these issues. > 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 > upon us. If its money related then they usually talk to those to whom they gave the money to. > 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 > maintainence problem. There are only a few hooks that really do not cost much in terms of maintenance. > 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. Can we match the performance of the TOE? I doubt that general purpose processors have the capabilities to get there. - 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
