Evgeniy Polyakov wrote: > > I see your point, and respectfully disagree. > The more complex userspace interface we create the less users > it will have. It is completely unconvenient to read 100 bytes > and receive only 80, since 20 were eaten by header. And what > if we need only 20, but packet contains 100, introduce per packet > head pointer? For purpose of benchmarking it works perfectly - read > the whole packet, one can event touch that data to emulate real > work, but for the real world it becomes practically unusabl. >
In a straight-forward user-mode library using existing interfaces the message would be interleaved with the headers in the inbound ring. While the inbound ring is part of user memory, it is not what the user would process from, that would be the buffer they supplied in a call to read() or recvmsg(), that buffer would have to make no allowances for interleaved headers. Enabling zero-copy when a buffer is pre-posted is possible, but modestly complex. Research on MPI and SDP have generally shown that the unless the pinning overhead is eliminated somehow that the buffers have to be quite large before zero-copy reception becomes a benefit. vj_netchannels represent a strategy of minimizing registration/pinning costs even if it means paying for an extra copy. Because the extra copy is closely tied to the activation of the data sink consumer the cost of that extra copy is greatly reduced because it places the data in the cache immediately before the application will in fact use the received data. Also keep in mind that once the issues are resolved to allow the netchannel rings to be directly visible to a user-mode client that enhanced/specialized interfaces can easily be added in user-mode libraries. So focusing on supporting existing conventional interfaces is probably the best approach for the initial efforts. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
