On Mon, 2007-04-09 at 16:38 +0300, Avi Kivity wrote: > Moreover, some things just don't lend themselves to a userspace > abstraction. If we want to expose tso (tcp segmentation offload), we > can easily do so with a kernel driver since the kernel interfaces are > all tso aware. Tacking on tso awareness to tun/tap is doable, but at > the very least wierd.
It is kinda weird, yes, but it certainly makes sense. All the arguments for tso apply in triplicate to userspace packet sends... > > We're dealing with the tun/tap device here, not a socket. > > Hmm. tun actually has aio_write implemented, but it seems synchronous. > So does the read path. > > If these are made truly asynchronous, and the write path is made in > addition copyless, then we might have something workable. I still > cringe at having a pagetable walk in order to deliver a 1500-byte packet. Right, now we're talking! However, it's not clear to me why creating an skb which references a kvm guest's memory doesn't need a pagetable walk, but a packet in (other) userspace memory does? My conviction which started this discussion is that if we can offer an efficient interface for kvm, we should be able to offer an efficient interface for any (other) userspace. As to async, I'm not *so* worried about that for the moment, although it would probably be nicer to fail than to block. Otherwise we could simply set an skb destructor to wake us up. > > Again, sendfile is a *much* harder problem than sending a single packet > > once, which is the question here. > > sendfile() is a *different* problem. It doesn't need completion because > the data is assumed not to change under it. Well, let's not argue over that, it's irrelevant. Hopefully we can do that over a beer or equivalent sometime. I think the first step is to see how much worse a decent userspace net driver is compared with the current in-kernel one. Rusty. - 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
