lkml.org 
[lkml]   [2000]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: zero-copy TCP
Date
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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.898 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site