On 04/21/11 07:09, Avi Kivity wrote: > On 04/21/2011 03:31 PM, Stefan Hajnoczi wrote: >> On Thu, Apr 21, 2011 at 9:07 AM, Avi Kivity<avi@xxxxxxxxxx> wrote: >> > Note I think in both cases we can make significant improvements: >> > - for VFs, steer device interrupts to the cpus which run the vcpus >> that will >> > receive the interrupts eventually (ISTR some work about this, but >> not sure) >> > - for virtio, use a DMA engine to copy data (I think there exists >> code in >> > upstream which does this, but has this been enabled/tuned?) >> >> Which data copy in virtio? Is this a vhost-net specific thing you're >> thinking about? > > There are several copies. > > qemu's virtio-net implementation incurs a copy on tx and on rx when > calling the kernel; in addition there is also an internal copy: > > /* copy in packet. ugh */ > len = iov_from_buf(sg, elem.in_num, > buf + offset, size - offset); > > In principle vhost-net can avoid the tx copy, but I think now we have 1 > copy on rx and tx each. So there is a copy internal to qemu, then from qemu to the host tap device and then tap device to a physical NIC if the packet is leaving the host? Is that what the zero-copy patch set is attempting - bypassing the transmit copy to the macvtap device? > > If a host interface is dedicated to backing a vhost-net interface (say > if you have an SR/IOV card) then you can in principle avoid the rx copy > as well. > > An alternative to avoiding the copies is to use a dma engine, like I > mentioned. > How does the DMA engine differ from the zero-copy patch set? David -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
