Re: [Qemu-devel] [PATCH V5 16/18] virtio-pci: increase the maximum number of virtqueues to 513

[Jason Wang <jasowang@redhat.com>]

On Wed, Apr 8, 2015 at 4:41 PM, Alexander Graf <agraf@suse.de> wrote:
> 
> 
> On 08.04.15 10:29, Jason Wang wrote:
>>  
>>  
>>  On Wed, Apr 8, 2015 at 2:33 AM, Alexander Graf <agraf@suse.de> 
>> wrote:
>>>  On 04/07/2015 08:06 PM, Luigi Rizzo wrote:
>>>> 
>>>> 
>>>>  On Tue, Apr 7, 2015 at 6:54 PM, Alexander Graf <agraf@suse.de> 
>>>> wrote:
>>>>>  On 04/01/2015 10:15 AM, Jason Wang wrote:
>>>>>>  This patch increases the maximum number of virtqueues for pci 
>>>>>> from 64
>>>>>>  to 513. This will allow booting a virtio-net-pci device with 
>>>>>> 256 queue
>>>>>>  pairs.
>>>>>>  ...    * configuration space */
>>>>>>    #define VIRTIO_PCI_CONFIG_SIZE(dev)    
>>>>>>  VIRTIO_PCI_CONFIG_OFF(msix_enabled(dev))
>>>>>>    -#define VIRTIO_PCI_QUEUE_MAX 64
>>>>>>  +#define VIRTIO_PCI_QUEUE_MAX 513
>>>>> 
>>>>>  513 is an interesting number. Any particular reason for it? Maybe
>>>>>  this was mentioned before and I just missed it ;)
>>>>> 
>>>> 
>>>>  quite large, too. I thought multiple queue pairs were useful
>>>>  to split the load for multicore machines, but targeting VMs with
>>>>  up to 256 cores (and presumably an equal number in the host)
>>>>  seems really forward looking.
>>> 
>>>  They can also be useful in case your host tap queue is full, so 
>>> going
>>>  higher than the host core count may make sense for throughput.
>>> 
>>>  However, I am in doubt that there is a one-size-fits-all answer to
>>>  this. Could we maybe make the queue size configurable via a qdev
>>>  property?
>>  
>>  We can do this on top but I'm not sure I understand the question. 
>> Do you
>>  mean a per-device limitation?
> 
> Ok, let me rephrase the question. Why isn't the limit 64k? 

Because there's no real use case for 64k but I agree to make more space 
for the future extension.
 
> Would we hit
> resource constraints? 

Probably not since VirtQueue is rather small. 64K will consume about 4 
or 5 MB, not sure it was too big but looks ok.

> Imagine that in Linux 5.0 the kernel tap interface
> extends to way more queues, we'd be stuck in the same situation as
> today, no?

Yes, but any limit will be exceeded in the future.

> 
> 
> Alex