qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] virtio-net: Make virtio queue sizes configurabl


From: Patrik Hermansson
Subject: Re: [Qemu-devel] [PATCH] virtio-net: Make virtio queue sizes configurable
Date: Tue, 15 Mar 2016 20:29:19 +0100

Hi Michael

Thanks for looking into the patch and for your comments.

2016-03-15 5:50 GMT+01:00 Michael S. Tsirkin <address@hidden>:
> On Fri, Nov 27, 2015 at 04:02:39PM +0100, Patrik Hermansson wrote:
>> This patch adds the option to specify virtio queue sizes. Currently the
>> queue sizes is hard coded to 256, which might not be suitable for all types
>> of applications.
>
> Any more data here? 256 packets seems plenty. Is there a chance
> your application does not support indirect descriptors?
> That's a better approach I think.

My application within the VM is using DPDK(2.0) virtio PMD and even if
it seems to have been attempts
getting support for indirect descriptors it does not seems it have
reached mainline.
To be honest I hadn't heard about indirect descriptors in virtio until
you mentioned it so
I still have some homework to do, but it seems  to be a much more
attractive solution
if such support exists in my case.

With 256 descriptors I see some problems with sporadic packet drops
from time to time
which I believe have to do with qemu getting rescheduled, increasing
the queue to 1024
seems to remedy the problem. My beliefs is that it is due the process
getting some more
headroom until packets are getting dropped.

>
>> This patch makes it possible to specify the queue size between
>> 256 to 1024.
>>
>> The minimum value is chosen based on the current sizes of the virtio
>> queues. The maximum queue size is based upon VIRTQUEUE_SIZE_MAX.
>
> To me, this seems excessive.  For example, 1024 will break if we have to
> add a virtio net header entry (on old kernels).
>

1024 were chosen due to assertion that the queue were not allowed to greater
than VIRTQUEUE_SIZE_MAX. I can lower the upper limit and do some more
measurements, but maybe it is the wrong path to go regardless?

Thanks,
Patrik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]