qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH V5 16/18] virtio-pci: increase the ma


From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH V5 16/18] virtio-pci: increase the maximum number of virtqueues to 513
Date: Wed, 08 Apr 2015 10:41:40 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0


On 08.04.15 10:29, Jason Wang wrote:
> 
> 
> On Wed, Apr 8, 2015 at 2:33 AM, Alexander Graf <address@hidden> wrote:
>> On 04/07/2015 08:06 PM, Luigi Rizzo wrote:
>>>
>>>
>>> On Tue, Apr 7, 2015 at 6:54 PM, Alexander Graf <address@hidden> 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? Would we hit
resource constraints? 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?


Alex



reply via email to

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