[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1175821357.12230.642.camel@localhost.localdomain>
Date: Fri, 06 Apr 2007 11:02:37 +1000
From: Rusty Russell <rusty@...tcorp.com.au>
To: Avi Kivity <avi@...ranet.com>
Cc: Ingo Molnar <mingo@...e.hu>, kvm-devel@...ts.sourceforge.net,
netdev <netdev@...r.kernel.org>
Subject: Re: [kvm-devel] QEMU PIC indirection patch for in-kernel APIC work
On Thu, 2007-04-05 at 10:17 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > You didn't quote Anthony's point about "it's more about there not being
> > good enough userspace interfaces to do network IO."
> >
> > It's easier to write a kernel-space network driver, but it's not
> > obviously the right thing to do until we can show that an efficient
> > packet-level userspace interface isn't possible. I don't think that's
> > been done, and it would be interesting to try.
> >
>
> In the case of networking, the copyful interfaces on receive are driven
> by the hardware not knowing how to split the header from the data. On
> transmit I agree, it could be made copyless from userspace (somthing
> like sendfilev, only not file oriented).
Hi Avi,
I don't think you've thought about this very hard. The receive copy is
completely independent with whether the packet is going to the guest via
a kernel driver or via userspace, so not relevant.
And if all packets from the card are going to the guest, you can
deliver directly. Userspace or kernel, no difference.
And we have a "sendfilev not file oriented": it's called "writev" 8)
An in-kernel driver can avoid system call overhead and page references.
But a better tap device helps more than just KVM.
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists