TCP mmap (was Re: [PATCH] f_op->poll() without lock_kernel())

From: dean gaudet (dgaudet-list-linux-kernel@arctic.org)
Date: Sat Apr 22 2000 - 01:45:50 EDT

  • Next message: Keith Owens: "Re: [RFC] Flat /lib/modules/`uname -r`"

    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 : Sat Apr 22 2000 - 01:52:30 EDT