[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.028 / U:10.652 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site