Re: zero-copy TCP

From: dean gaudet (dean-list-linux-kernel@arctic.org)
Date: Tue Sep 05 2000 - 15:56:56 EST


On Mon, 4 Sep 2000, Jamie Lokier wrote:

> Alan Cox wrote:
> > > It's not faster than card->card DMA, which falls out naturally from my
> > > zero-copy proposal :-)
> >
> > We already support card->card DMA for routing with fastrouting
>
> ..but not for user space proxies which was the above's context.
>
> Still, the fastrouting proves card->card DMA actually works.

this is just a comment from the "real world" (for some definition of
real).

my last job was to take a hosted mail system from 3 million mailboxes to
over 25 million (the new design is targetted for 100 million). part of
this architecture includes a userspace proxy at the front -- all data goes
through the proxy.

from the point of view of scaling and robustness it never made any sense
for us to put more than about 2Mbyte/s through one of these proxy boxes.
which is pretty easy to handle even if you're doing another copy of all
the data. (although my proxy code included a userland zero-copy
implementation, used readv/writev and was otherwise optimised.)

the part which actually broke down at that scale was handling the number
of concurrent connections, not the total bandwidth.

and, alan has pointed this out before -- it's not just concurrent
LAN-speed connections which are of interest. it's concurrent modem users.
all the current benchmarks are LAN-style and misrepresent the real-world
by a lot.

i know net connections are getting faster -- but are they ahead of the
moore's law curve or behind it? it may be better (in the long run) for
linux to work on scaling concurrent connections than work on getting the
last couple percentages out of raw LAN transfers. but i'm biased because
i've worked in the internet service space for too long :)

unfortunately i think scaling to tens of thousands of modem connections is
going to require some different programming paradigms -- the rt signal
stuff is a start. but there's probably a lot of wins yet to be had from
deliberately delaying servicing of some connections in order to achieve
better cache usage. (consider the case of the big static-content FTP/HTTP
server and trying to arrange for a few hundred connections to be on
roughly the same page at roughly the same time. i think there's wins
there, but the math is hard :)

-dean

-
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/



This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:22 EST