From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
cornelia.huck@de.ibm.com, Alexander Graf <agraf@suse.de>,
qemu-devel@nongnu.org, Keith Busch <keith.busch@intel.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-ppc@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
Amit Shah <amit.shah@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH V4 00/19] Support more virtio queues
Date: Thu, 19 Mar 2015 10:23:04 +0100 [thread overview]
Message-ID: <20150319102019-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <1426750976.5002.10@smtp.corp.redhat.com>
On Thu, Mar 19, 2015 at 03:42:56PM +0800, Jason Wang wrote:
>
>
> On Thu, Mar 19, 2015 at 3:32 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >On Thu, Mar 19, 2015 at 01:24:53PM +0800, Jason Wang wrote:
> >> On Wed, Mar 18, 2015 at 8:58 PM, Michael S. Tsirkin
> >><mst@redhat.com> wrote:
> >> >On Wed, Mar 18, 2015 at 05:34:50PM +0800, Jason Wang wrote:
> >> >> We current limit the max virtio queues to 64. This is not sufficient
> >> >> to support multiqueue devices (e.g recent Linux support up to 256
> >> >> tap queues). So this series tries to let virtio to support more
> >>queues.
> >> >> No much works need to be done except:
> >> >> - Introducing transport specific queue limitation.
> >> >> - Let each virtio transport to use specific limit.
> >> >> - Speedup the MSI-X masking and unmasking through per vector queue
> >> >> list, and increase the maximum MSI-X vectors supported by qemu.
> >> >> - With the above enhancements, increase the maximum number of
> >> >> virtqueues supported by PCI from 64 to 513.
> >> >> - Compat the changes for legacy machine types.
> >> >
> >> >What are the compatibility considerations here?
> >> Two considerations:
> >> 1) To keep msix bar size to 4K for legacy machine types
> >> 2) Limit the pci queue max to 64 for legacy machine types
> >
> >2 seems not relevant to me.
>
> If we don't limit this. Consider migration from 2.4 to 2.3
>
> Before migration
>
> write 0 to queue_sel
> write 100 to queue_sel
> read queue_sel will get 100
>
> but after migration
>
> write 0 to queue_sel
> write 100 to queue_sel
> read queue_sel will get 0
>
> The hardware behavior was changed after migration.
But this driver is out of spec - drivers are not supposed to select
non-existent queues. So this doesn't matter.
> Another reason is not wasting memory for the extra virtqueues allocated for
> legacy machine types.
If that's a significant amount of memory, we need to work
to reduce memory consumption for new machine types.
Not many people use the compat machine types, especially
upstream.
--
MST
next prev parent reply other threads:[~2015-03-19 9:23 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-18 9:34 [Qemu-devel] [PATCH V4 00/19] Support more virtio queues Jason Wang
2015-03-18 9:34 ` [Qemu-devel] [PATCH V4 01/19] pc: add 2.4 machine types Jason Wang
2015-03-18 9:34 ` [Qemu-devel] [PATCH V4 02/19] spapr: add machine type specific instance init function Jason Wang
2015-03-18 9:34 ` [Qemu-devel] [PATCH V4 03/19] ppc: spapr: add 2.4 machine type Jason Wang
2015-03-18 9:34 ` [Qemu-devel] [PATCH V4 04/19] monitor: replace the magic number 255 with MAX_QUEUE_NUM Jason Wang
2015-03-18 9:34 ` [Qemu-devel] [PATCH V4 05/19] monitor: check return value of qemu_find_net_clients_except() Jason Wang
2015-03-18 9:34 ` [Qemu-devel] [PATCH V4 06/19] virtio-ccw: using VIRTIO_NO_VECTOR instead of 0 for invalid virtqueue Jason Wang
2015-03-18 13:08 ` Michael S. Tsirkin
2015-03-20 7:39 ` Cornelia Huck
2015-03-21 18:27 ` Michael S. Tsirkin
2015-03-23 9:02 ` Cornelia Huck
2015-03-18 9:34 ` [Qemu-devel] [PATCH V4 07/19] virtio-net: validate backend queue numbers against bus limitation Jason Wang
2015-03-18 13:05 ` Michael S. Tsirkin
2015-03-19 5:26 ` Jason Wang
2015-03-18 9:34 ` [Qemu-devel] [PATCH V4 08/19] virtio-net: fix the upper bound when trying to delete queues Jason Wang
2015-03-18 13:06 ` Michael S. Tsirkin
2015-03-19 5:28 ` Jason Wang
2015-03-18 9:34 ` [Qemu-devel] [PATCH V4 09/19] virito: introduce bus specific queue limit Jason Wang
2015-03-20 10:20 ` Cornelia Huck
2015-03-31 2:34 ` Jason Wang
2015-03-18 9:35 ` [Qemu-devel] [PATCH V4 10/19] virtio-ccw: introduce ccw " Jason Wang
2015-03-20 11:33 ` Cornelia Huck
2015-03-31 2:36 ` Jason Wang
2015-03-18 9:35 ` [Qemu-devel] [PATCH V4 11/19] virtio-s390: switch to bus " Jason Wang
2015-03-20 11:34 ` Cornelia Huck
2015-03-18 9:35 ` [Qemu-devel] [PATCH V4 12/19] virtio-mmio: " Jason Wang
2015-03-18 9:35 ` [Qemu-devel] [PATCH V4 13/19] virtio-pci: switch to use " Jason Wang
2015-03-18 9:35 ` [Qemu-devel] [PATCH V4 14/19] virtio: introduce vector to virtqueues mapping Jason Wang
2015-03-20 11:39 ` Cornelia Huck
2015-03-31 2:37 ` Jason Wang
2015-03-18 9:35 ` [Qemu-devel] [PATCH V4 15/19] virtio: introduce virtio_queue_get_index() Jason Wang
2015-03-18 9:35 ` [Qemu-devel] [PATCH V4 16/19] virtio-pci: speedup MSI-X masking and unmasking Jason Wang
2015-03-18 9:35 ` [Qemu-devel] [PATCH V4 17/19] virtio-pci: increase the maximum number of virtqueues to 513 Jason Wang
2015-03-18 9:35 ` [Qemu-devel] [PATCH V4 18/19] pci: remove hard-coded bar size in msix_init_exclusive_bar() Jason Wang
2015-03-18 12:52 ` Michael S. Tsirkin
2015-03-19 5:19 ` Jason Wang
2015-03-19 10:09 ` Michael S. Tsirkin
2015-03-20 5:43 ` Jason Wang
2015-03-18 9:35 ` [Qemu-devel] [PATCH V4 19/19] virtio-pci: introduce auto_msix_bar_size property Jason Wang
2015-03-18 12:57 ` Michael S. Tsirkin
2015-03-19 5:23 ` Jason Wang
2015-03-19 10:01 ` Michael S. Tsirkin
2015-03-20 5:35 ` Jason Wang
2015-03-19 5:23 ` Jason Wang
2015-03-19 10:02 ` Michael S. Tsirkin
2015-03-20 5:38 ` Jason Wang
2015-03-18 12:58 ` [Qemu-devel] [PATCH V4 00/19] Support more virtio queues Michael S. Tsirkin
2015-03-19 5:24 ` Jason Wang
2015-03-19 7:32 ` Michael S. Tsirkin
2015-03-19 7:42 ` Jason Wang
2015-03-19 9:23 ` Michael S. Tsirkin [this message]
2015-03-20 5:11 ` 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=20150319102019-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=agraf@suse.de \
--cc=amit.shah@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=jasowang@redhat.com \
--cc=keith.busch@intel.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=rth@twiddle.net \
--cc=stefanha@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.