[lkml]   [2000]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: zero-copy TCP
At 22:53 03/09/00, Linus Torvalds wrote:
> >Ugh. User space DMA gets complicated quickly. The performance question
> >is, perhaps, can you do this without a TLB flush (but with locking the
> >struct page of course). Note that it doesn't matter if another thread,
> >and this includes truncate/write in another thread, clobbers the page
> >data. That's just the normal effect of two concurrent writers to the
> >same memory.
>People who claim "zero-copy" is a great thing often ignore the costs of
>_not_ copying altogether.

many people (myself included) have been experimenting with zerocopy
in my case, i've been working on it as time permits for quite a few months
now, and am about on my fourth rewrite.

i've found exactly what you state about the bad things that occur when you
associate zerocopy infrastructure with user-space code. some of the the MM
tricks required for handling individual pages effectively kills any
performance gain.

however, approaching it from the other angle of "buffers pinned in kernel
memory" can give you a huge win.
for the application which prompted me to begin looking at this problem,
where packets typically go network -> RAM -> network, providing a zerocopy
infrastructure for (a) viewing incoming packet streams pinned in kernel
memory from user-space [a sort-of SIGIO with pointers to the buffers], and
(b) hooks for user-space directing the kernel to do things with these
buffers [eg. "queue buffer A for output on fd Y"] has provided an immediate
60% performance gain.

performance was previously pinned on front-side-bus (or memory) bandwidth.

the interfaces are a bit hacky, and the way one has to queue packets for
tcp-write is awful right now, but i hope these can be cleaned up over time.

network cards which offload the IP & TCP checksum calculation isn't even
required; provided the incoming checksum is preserved, the original pseudo
TCP header can be "reversed out" without having to re-read the entire
packet payloads again.



Lincoln Dale Content Services Business Unit cisco Systems, Inc. | |
|| ||
+1 (408) 525-1274 bldg G, 170 West Tasman |||| ||||
+61 (3) 9659-4294 << San Jose CA 95134 ..:||||||:..:||||||:..

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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