Re: [PATCH 4/5] kvm: qemu: Use vringfd to eliminate copies

[Mark McLoughlin <markmc@redhat.com>]

Hi Anthony,

On Sat, 2008-06-14 at 18:28 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > Where a VLAN consists only of a single tap interface on the
> > host side and a single virtio interface on the guest side,
> > we can use the tun/tap driver's vringfd support to eliminate
> > copies.
> >
> > We set up a vringfd for both rings and pass them to the
> > tun/tap driver. When the guest informs us of the location of
> > the ring pages, we use the VRINGSETINFO ioctl() to inform
> > the /dev/vring driver.
> >   
> 
> This patch set is useful for testing (I have one too in my patch 
> queue).

Ah, didn't know of your queue ... Is it (http://hg.codemonkey.ws/) down
atm?

>   We need to make some more pervasive changes to QEMU though to 
> take advantage of vringfd upstream.
> 
> Specifically, we need to introduce a RX/TX buffer adding/polling API for 
> VLANClientState.  We can then use this within a vringfd VLAN client to 
> push the indexes to vringfd.

I don't think I'm following you fully on this.

The TX side is fine - guest adds buffer to ring, virtio VLANClient calls
->add_tx_buffer() on every other VLANClient, waits until all are
finished sending and notifies the guest that we're done.

But the RX side? The guest allocates the buffers, so does the virtio
VLANClient divide those buffers between every other VLANClient? Or does
it make all buffers available to all clients and have a way of locking a
buffer just before using it? The former would be a waste, and we don't
have any way of doing the latter right now with vringfd.

Also, since a client could be supplied with RX buffers from multiple
other clients, tun/tap would need to support multiple RX rings.

It really makes one wonder whether QEMU's VLAN feature is really worth
all this bother.

Oh yes, there's also GSO feature negotiation; you'd need to have a way
of figuring out what clients support what GSO features, which is
fine ... expect for what to do in the case of hotplug.

>   We can't use the base/limit stuff in QEMU so we have to do
> translation.  Not a big deal really.

Yeah, that's not a problem.

> Have you benchmarked the driver?  I wasn't seeing great performance 
> myself although I think that was due to some bugs in the vringfd code.

Nope, I haven't done any real benchmarking with it yet.

Cheers,
Mark.