qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Jason Wang <jasowang@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	qemu-ppc@nongnu.org, cornelia.huck@de.ibm.com,
	Paolo Bonzini <pbonzini@redhat.com>,
	Luigi Rizzo <rizzo@iet.unipi.it>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [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	[thread overview]
Message-ID: <5524E9C4.50006@suse.de> (raw)
In-Reply-To: <1428481762.29276.3@smtp.corp.redhat.com>



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? 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	other threads:[~2015-04-08  8:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-01  8:14 [Qemu-devel] [PATCH V5 00/18] Support more virtio queues Jason Wang
2015-04-01  8:14 ` [Qemu-devel] [PATCH V5 01/18] virtio-net: fix the upper bound when trying to delete queues Jason Wang
2015-04-01  8:14 ` [Qemu-devel] [PATCH V5 02/18] pc: add 2.4 machine types Jason Wang
2015-04-01  8:14 ` [Qemu-devel] [PATCH V5 03/18] spapr: add machine type specific instance init function Jason Wang
2015-04-01  8:14 ` [Qemu-devel] [PATCH V5 04/18] ppc: spapr: add 2.4 machine type Jason Wang
2015-04-01  8:14 ` [Qemu-devel] [PATCH V5 05/18] monitor: replace the magic number 255 with MAX_QUEUE_NUM Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 06/18] monitor: check return value of qemu_find_net_clients_except() Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 07/18] virtio-ccw: using VIRTIO_NO_VECTOR instead of 0 for invalid virtqueue Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 08/18] virtio: introduce bus specific queue limit Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 09/18] virtio-ccw: introduce ccw " Jason Wang
2015-04-02 13:47   ` Cornelia Huck
2015-04-03  8:53     ` Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 10/18] virtio-s390: switch to bus " Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 11/18] virtio-mmio: " Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 12/18] virtio-pci: switch to use " Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 13/18] virtio: introduce vector to virtqueues mapping Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 14/18] virtio: introduce virtio_queue_get_index() Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 15/18] virtio-pci: speedup MSI-X masking and unmasking Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 16/18] virtio-pci: increase the maximum number of virtqueues to 513 Jason Wang
2015-04-07 16:54   ` Alexander Graf
2015-04-07 18:06     ` Luigi Rizzo
2015-04-07 18:33       ` Alexander Graf
2015-04-08  8:29         ` Jason Wang
2015-04-08  8:41           ` Alexander Graf [this message]
2015-04-08  9:04             ` Jason Wang
2015-04-08  8:27       ` Jason Wang
2015-04-08 13:23       ` Michael S. Tsirkin
2015-04-08  8:10     ` Jason Wang
2015-04-08  8:13       ` Alexander Graf
2015-04-08  8:30         ` Jason Wang
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 17/18] pci: remove hard-coded bar size in msix_init_exclusive_bar() Jason Wang
2015-04-01  9:18   ` Michael S. Tsirkin
2015-04-01 10:12     ` Jason Wang
2015-04-01 10:20       ` Michael S. Tsirkin
2015-04-01  8:15 ` [Qemu-devel] [PATCH V5 18/18] virtio-pci: introduce auto_msix_bar_size property Jason Wang
2015-04-01  9:20   ` Michael S. Tsirkin
2015-04-01 10:14     ` Jason Wang
2015-04-02 13:43 ` [Qemu-devel] [PATCH V5 00/18] Support more virtio queues Cornelia Huck
2015-04-03  8:52   ` Jason Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5524E9C4.50006@suse.de \
    --to=agraf@suse.de \
    --cc=cornelia.huck@de.ibm.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rizzo@iet.unipi.it \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).