On Fri, 2006-04-28 at 10:55 -0700, Caitlin Bestler wrote: > 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.
Just to be clear here: I agree with Dave that without classifying hardware, there's no point (and much pain) in going all the way to userspace with the channel (ie. mmap). If you're going to copy anyway, might as well do it in the socket's read() call: then the user can then aim the copy exactly where they want, too. We'll need that TCP code in the kernel for the foreseeable future anyway 8) However, in future, if intelligent cards exist, having an API which lets them do zero-copy and not overly penalize less intelligent cards makes sense. Side note: my Xen I/O patches allow the implementation of exactly this kind of virtual hardware (no coincidence 8), so intelligent cards might not be as far away as you think... > 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. Absolutely. Cheers! Rusty. -- ccontrol: http://ozlabs.org/~rusty/ccontrol - 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
