On 04/25/2011 08:49 PM, David Ahern wrote:
>
> 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?
There is no internal copy on tx, just rx.
So:
virtio-net: 1 internal rx, 1 kernel/user rx, 1 kernel/user tx
vhost-net: 1 internal rx, 1 internal tx
Is that what the zero-copy patch set is attempting - bypassing the
transmit copy to the macvtap device?
Yes.
>
> 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?
The DMA engine does not avoid the copy, it merely uses a device other
than the cpu to perform it. It offloads the cpu but still loads the
interconnect. True zero-copy avoids both the cpu load and the
interconnect load.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html