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

[Anthony Liguori <aliguori@us.ibm.com>]

Mark McLoughlin wrote:
> Hi Anthony,
>
> On Sat, 2008-06-14 at 18:28 -0500, Anthony Liguori wrote:
>   
>> 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?
>   

It's up now.

>>   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?

This is where things get tricky.  Internally, it will have to copy the 
TX buffer into each of the clients RX buffers.  We need to special case 
the circumstance where the only other VLANClientState is a vringfd 
client so that we can pass the RX buffer directly to it.  Haven't come 
up with a perfect API just yet but that's what we need to do.

>  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.
>   

It's necessary for upstream acceptance and solving the problem right 
will give us vringfd support for the e1000 for free.

> 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.
>   

Right, we need a feature API.

Regards,

Anthony Liguori

>>   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.
>
>