[lkml]   [1999]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: zero-copy TCP fileserving
On Thu, 3 Jun 1999, Richard B. Johnson wrote:
> Don't forget that it is unlikely that a new protocol will be invented
> to support zero-copy. Therefore we have the problem of:
> (1) Get only IP header from controller.
> (2) Process header to see who/what/why/where.
> (3) Page in user buffer, could start on any boundary. Could be too
> small for the whole packet. In the meantime more packets are
> arriving.

Yes, reception is hairy. But (at least I) am talking about sending - I see
more scenarios where a single computer sends data to many others, than a
single computer receives a lot of data (and needs to do it extremely

Sending is technically much easier to make zero-copy. As others have
pointed out there are issues regarding threading and TCP socket semantics
(like write()/sendmsg() returning before the last fragment is ACK'ed ?)
which relate to the handling of the locked pages. But the actual NIC
sending is easy to do - at least our NIC HW can receive DMA lists telling
it to send an IP header from position X, then a payload from position Y,
etc etc.

Speaking of checksumming outgoing fragments in HW - it is trivial to make
the HW calculate the checksum itself, but I see a problem with having it
inserting it in the stream - mainly because the checksum field passes
through the HW _before_ the data it is supposed to checksum. How is this
solved in the HW that can do outgoing checksumming ? Does it have a FIFO
large enough to keep an MTU (and manipulate the header) ?


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 13:52    [W:0.107 / U:0.668 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site