qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] [PATCH V7 00/16] Support more virtio queues


From: Jason Wang
Subject: [Qemu-devel] [PATCH V7 00/16] Support more virtio queues
Date: Thu, 23 Apr 2015 14:21:33 +0800

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. This is used to
  simplify increasing the limitation for one transport without
  harming the rest.
- 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 1024.
- Compat legacy virtio queue limit

With this patch, we can support up to 256 queues. Since x86 can only
allow about 240 interrupt vectors for MSI-X, current Linux driver can
only have about 80 queue pairs has their private MSI-X interrupt
vectors. With sharing IRQ with queue pairs (RFC posted in
https://lkml.org/lkml/2014/12/25/169), Linux driver can have up
to about 186 queue pairs has their private MSI-X interrupt vectors.

Stress/migration test on virtio-pci, compile test on other
targets. And make check on s390x-softmmu and ppc64-softmmu.

Cc: Paolo Bonzini <address@hidden>
Cc: Richard Henderson <address@hidden>
Cc: Michael S. Tsirkin <address@hidden>
Cc: Alexander Graf <address@hidden>
Cc: Keith Busch <address@hidden>
Cc: Kevin Wolf <address@hidden>
Cc: Stefan Hajnoczi <address@hidden>
Cc: Christian Borntraeger <address@hidden>
Cc: Cornelia Huck <address@hidden>
Cc: Amit Shah <address@hidden>
Cc: address@hidden

Please review

Thanks

Changes from V6:
- Tweak some commit logs
- Replace the missed VIRTIO_PCI_MAX in ccw with a bus specific limit
- Bump the pci queue limit from 513 to 1024

Changes from V5:
- Rebase to HEAD
- Drop the patch that introduce helper to get vq index since there has
  already one
- Don't try to solve the migration compatibility issue for invalid
  configuration like vectors > 128 with only 64 virto queues. This is
  done by let msix calaucalte the correct bar size and drop the patch
  18 that intrdouces the auto_msix_bar_size.
- Cleanup the bar size and pba offset calcuation code
- Add a comment to explain the new virtio pci queue limit number 513

Changes from V4:
- Drop the patch of bus limitation validation and send it as an
  independent patch
- Don't let the virtio-pci to calculate the MSI-X bar size, instead,
  tell the msix code whether or not to use legacy bar size and let it
  to do this
- Make sure the MSI-X bar size is at least 4K
- Subject typos fixes for patch 8
- Mention adapter routes changes in the commit log of patch 9
- Only use the vector to queue list for virtio-pci to avoid the
  unnecessary possible overhead on other transport.

Changes from V3:
- rebase to master and target to 2.4
- handling compat issues for spapr
- fixes for hmp command completion when we have a nic with 256 queues
- using VIRTIO_NO_VECTOR instead of 0 for invalid virtqueue in
  virtio-ccw
- fix compile issues for ppc64-softmmu
- don't export VIRTIO_CCW_QUEUE_MAX by introducing a gsi limit and
  inherit in ccw
- use transport specific queue limit in virtio-serial
- correct the stale comment for AdapterRoutes and move it to ccw patch
- replace 128 with queue_max + 64 and add a comment for this in
  virtio_ccw_notify()

Changes from V2:
- move transport specific limitation to their implementation. (The
  left is VIRTIO_CCW_QUEUE_MAX since I fail to find a common header
  files other than virtio.h)
- use virtio_get_queue_ma) if possible in virtio.c
- AdapterRoutes should use ccw limit
- introduce a vector to queue mapping for virito devices and speedup
  the MSI-X masking and unmasking through this.

Changes from V1:
- add a validation against the bus limitation
- switch to use a bus specific queue limit instead of a global one,
  this will allow us to just increase the limit of one transport
  without disturbing others.
- only increase the queue limit of virtio-pci
- limit the maximum number of virtio queues to 64 for legacy machine
  types

Jason Wang (16):
  virtio-net: fix the upper bound when trying to delete queues
  pc: add 2.4 machine types
  spapr: add machine type specific instance init function
  ppc: spapr: add 2.4 machine type
  monitor: replace the magic number 255 with MAX_QUEUE_NUM
  monitor: check return value of qemu_find_net_clients_except()
  virtio-ccw: using VIRTIO_NO_VECTOR instead of 0 for invalid virtqueue
  virtio: introduce bus specific queue limit
  virtio-ccw: introduce ccw specific queue limit
  virtio-s390: switch to bus specific queue limit
  virtio-mmio: switch to bus specific queue limit
  virtio-pci: switch to use bus specific queue limit
  virtio: introduce vector to virtqueues mapping
  virtio-pci: speedup MSI-X masking and unmasking
  virtio-pci: increase the maximum number of virtqueues to 513
  pci: remove hard-coded bar size in msix_init_exclusive_bar()

 hw/char/virtio-serial-bus.c    |  2 +-
 hw/i386/pc_piix.c              | 34 ++++++++++++++++---
 hw/i386/pc_q35.c               | 31 ++++++++++++++++--
 hw/net/virtio-net.c            |  6 ++--
 hw/pci/msix.c                  | 30 ++++++++++-------
 hw/ppc/spapr.c                 | 59 +++++++++++++++++++++++++++++++--
 hw/s390x/s390-virtio-bus.c     |  7 ++--
 hw/s390x/s390-virtio-ccw.c     |  7 ++--
 hw/s390x/virtio-ccw.c          | 22 ++++++++-----
 hw/scsi/virtio-scsi.c          |  4 +--
 hw/virtio/virtio-mmio.c        |  7 ++--
 hw/virtio/virtio-pci.c         | 65 +++++++++++++++++++++++--------------
 hw/virtio/virtio.c             | 74 +++++++++++++++++++++++++++++++++---------
 include/hw/s390x/s390_flic.h   |  4 ++-
 include/hw/virtio/virtio-bus.h |  2 ++
 include/hw/virtio/virtio.h     |  6 ++--
 monitor.c                      | 25 +++++++-------
 17 files changed, 291 insertions(+), 94 deletions(-)

-- 
2.1.0




reply via email to

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