Messages in this thread |  | | Date | Tue, 5 Sep 2000 13:56:56 -0700 (PDT) | From | dean gaudet <> | Subject | Re: zero-copy TCP |
| |
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/
|  |