On Fri, 21 Apr 2000, David S. Miller wrote:
> Date: Fri, 21 Apr 2000 23:48:52 -0400 (EDT)
> From: Alexander Viro <viro@math.psu.edu>
>
> On Fri, 21 Apr 2000, David S. Miller wrote:
>
> > Some day it may be fun to mmap tcp sockets. It has to stay.
>
> Hey, it's your part of the tree, but... what kind of semantics one
> might want for mmap() on TCP link? I'm really curious...
>
> For received packets, they just "appear" in the mmap'd area,
> which is managed in a ring fashion using new/old indexes.
> User advances "old" as received frames are no longer needed
> and kernel advances "new" as new frames are received.
ok i'll bite.
i think that this might drive up TLB activity when you operate at scale
(1000s of tcp sessions), to the point that you don't get a win from the
technique.
> Transmit works similarly except that the management of the
> "old" and "new" is done by the kernel and user respectively.
>
> Essentially it's like moving the buffer management of an ethernet
> driver into user space, it's similar to what the UNET project
> did/proposed, except you don't need to give up all the advantages
> of TCP.
>
> It's just an idea, and one could implement this with zero
> copy pretty easily with special firmware on a gbit card for
> example. And it'll make happy the beowulf folks. :-)
yeah i guess it works as long as you keep the number of sessions low :)
i've been playing with a ring buffer technique for userland buffering in
which i share the buffer amongst all the sockets. it's actually the first
real use of readv() i've seen.
it's pretty nice -- requires very little memory per-session, great for
handling idle sessions and such... unlike the usual userland buffering
technique which is to allocate a 4k buffer per session and chew ram and
TLB entries.
i will send you a reference to the code when i release it.
-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:20 EST