Re: QEMU PIC indirection patch for in-kernel APIC work

Rusty Russell
2007-04-09T09:46:24Z

On Mon, 2007-04-09 at 10:10 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > I'm a little puzzled by your response. Hmm...
> >
> > lguest's userspace network frontend does exactly as many copies as
> > Ingo's in-host-kernel code. One from the Guest, one to the Guest.
>
> kvm pvnet is suboptimal now. The number of copies could be reduced by
> two (to zero), by constructing an skb that points to guest memory.
> Right now, this can only be done in-kernel.

Sorry, you lost me here. You mean both input and output copies can be
eliminated? Or are you talking about another two copies somewhere?

But I don't get this "we can enhance the kernel but not userspace" vibe
8(

> With current userspace networking interfaces, one cannot build a network
> device that has less than one copy on transmit, because sendmsg() *must*
> copy the data (as there is no completion notification).

Why are you talking about sendmsg()? Perhaps this is where we're
getting tangled up.

We're dealing with the tun/tap device here, not a socket.

> sendfilev(),
> even if it existed, cannot be used: it is copyless, but lacks completion
> notification. It is useful only on unchanging data like read-only files.

Again, sendfile is a *much* harder problem than sending a single packet
once, which is the question here.

Rusty.