qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jason Wang
Subject: Re: [Qemu-devel] [PATCH V5 16/18] virtio-pci: increase the maximum number of virtqueues to 513
Date: Wed, 08 Apr 2015 17:04:02 +0800



On Wed, Apr 8, 2015 at 4:41 PM, Alexander Graf <address@hidden> wrote:


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?

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




reply via email to

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