> So perhaps there's a good argument to make that a Linux system with the > right hardware could be considered a core device. Likely any place you > have such a system it would be dedicated to just moving data as well as > possible, and let other systems do the other stuff. You wouldn't want > your server farm systems to also be your firewalls.
Why not? While Linux firewall performance is not flawless its problems (e.g. slow conntrack) seems to be mostly in an area where TOE cannot do much about. > Bottom line - these technologies seem to me to have a place in a well > designed network. I think there is a web page listing why it's bad, but here a quick summary: One worry is to debug it all together. Currently we have a single stack to debug, although it's already difficult to control the complexity as it grows more bells and whistles. Just take a look at Cisco IOS release notes to see how hard and difficult it is to get it all to work together. Another reason is that there are general doubts that TOE can keep up with the ever growing performance of CPUs. Even if Linux added it today it would be likely slower again a few months later. That is also a big difference to Cisco hardware. Linux usually runs on fast main CPUs (or if you run it on slow CPUs you normally don't expect the best network performance). And they get faster and faster constantly. Admittedly 10GB NICs are still a bit too fast for mainstream systems, but that seems to be mostly a problem outside the CPUs and it looks like the next generation of systems will catch up with enough bandwidth in this area. Also it tends to accelerate the wrong thing. On a lot of workloads the main problem is keeping a lot of different connections under control, and TOE tends to be slow at keeping connection information synchronized with the host. That is why the Linux strategy has been to ask for useful stateless offloads instead. Examples of this are checksum offload (long time classic), TSO (TCP segmentation offload), UFO (UDP segmentation offload), Intel iOAT (memcpy off load), RX hashing with MSI-X (not implemented yet, but basically it allows load balancing of incoming streams to CPU) Note that all these are more or less stateless offloads. iWARP is not clear yet what it is. From the meager bits of information about it that reached netdev so far it at least sounds it does RDMA and needs far more state than any of the other offloads we got so far and likely got the usual TOE scaling issues. It's also likely on the wrong side of Moore's law. -Andi - 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
