Re: [ANNOUNCE] kvm-guest-drivers-windows-2

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> Anthony Liguori wrote:
>>>> FWIW, virtio-net is much better with my patches applied.
>>>
>>> The can_receive patches?
>>>
>>> Again, I'm not opposed to them in principle, I just think that if 
>>> they help that this points at a virtio deficiency.  Virtio should 
>>> never leave the rx queue empty.  Consider the case where the virtio 
>>> queue isn't tied to a socket buffer, but directly to hardware.
>>
>> For RX performance:
>>
>>
>> right now
>> [  3]  0.0-10.0 sec  1016 MBytes    852 Mbits/sec
>>
>> revert tap hack
>> [  3]  0.0-10.0 sec    564 MBytes    473 Mbits/sec
>>
>> all patches applied
>> [  3]  0.0-10.0 sec  1.17 GBytes  1.01 Gbits/sec
>>
>> drop lots of packets
>> [  3]  0.0-10.0 sec  1.05 GBytes    905 Mbits/sec
>>
>>
>> The last patch is not in my series but it basically makes the ring 
>> size 512 and drops packets when we run out of descriptors.  That was 
>> to valid that we're not hiding a virtio deficiency.  The reason I 
>> want to buffer packets is that it avoids having to deal with 
>> tuning.   For vringfd/vmdq, we'll have to make sure to get the tuning 
>> right though.
>
> Okay; I'll apply the patches.  Hopefully we won't diverge too much 
> from upstream qemu.

I am going to push these upstream.  I need to finish the page_desc cache 
first b/c right now the version of virtio that could go into upstream 
QEMU has unacceptable performance for KVM.

Regards,

Anthony Liguori



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/