Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: zero-copy TCP | Date | 2 Sep 2000 23:33:27 -0700 |
| |
In article <20000903052244.B15788@pcep-jamie.cern.ch>, Jamie Lokier <lk@tantalophile.demon.co.uk> wrote: > >I just thought I'd mention that you can do zero copy TCP in and out >*without* any page marking schemes. All you need is a network card with >quite a lot of RAM and some intelligence. An Alteon could do it, with >extra RAM or an impressively underloaded network. > >(for example) http://www.digital.com/info/DTJS05/
The thing is, that at least historically it has always been a bad bet to bet on special-purpose hardware over general-purpose stuff.
What I'm saying is that basically you should not design your TCP layer around the 0.1% of cards that have tons of intelligence, when you have a general-purpose CPU that tends to be faster in the end.
The smart cards can actually have higher latency than just doing it the "stupid" way with the CPU. Yes, they'll offload some of the computation, and may make system throughput better, but at what cost?
[ Same old example: just calculate how quickly you can get your packet on the wire with a smart card that does checksumming in hardware, and do the same calculations with a CPU that does the checksums. Take into account that the checksum is at the _head_ of the packet. The CPU will win.
Proof: the data to be sent out is in RAM. In fact, often it is cached in the CPU these days. In order to start sending out the packet, the smart card has to move all of the data from RAM/cache over the bus to the card. It can only start actually sending after that. Cost: bus speed to copy it over.
In contrast, if you do it on the CPU, you can basically start feeding the packet out on the net after doing a CPU checksum that is limited by RAM/cache speeds. Bus speed isn't the limiting factor any more on packet latency, as you can send out the start of the packet on the network before the whole packet has even been copied over the internal bus! ]
So. Smart cards are not necessarily better for latency. They are certainly not cheaper. They _are_ better for throughput, no question about that. But so is adding another CPU. Or beefing up your memory subsystem. Or any number of other things that are more generic than some smart network card - and often cheaper because they are "standard components", useful regardless of _what_ you do.
End result: smart cards only make sense in systems that are really pushing the performance envelope. Which, after all, is not that common, as it's usually easier to just beef up the machine in other ways until the network is not the worst bottle-neck. Very few places outside benchmark labs have networks _that_ studly.
Right now gigabit is heavy-duty enough that it is worth smart cards. The same used to be true about the first generation of 100Mbit cards. The same will be true of 10Gbps cards in another few years. But basically, they'll probably always end up being the exception rather than the rule, unless they become so cheap that it doesn't matter. But "cheap" and "pushing the performance envelope" do not tend to go hand in hand.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |