Re: performance of virtual functions compared to virtio

[David Ahern <dsahern@gmail.com>]

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@redhat.com>  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