Messages in this thread | | | Date | Thu, 3 Jun 1999 23:08:52 +0200 (MET DST) | From | Bjorn Wesen <> | Subject | Re: 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 efficiently).
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) ?
/Bjorn
- 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/
| |