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

Re: [libvirt] [PATCH v2 01/12] Introduce /domain/devices/interface/driver/@queues attribute

On 14/05/13 17:33, Michal Privoznik wrote:
On 13.05.2013 22:38, Laine Stump wrote:
On 05/13/2013 01:22 PM, Michal Privoznik wrote:
This attribute is going to represent number of queues for
multique vhost network interface. This commit implements XML
extension part of the feature and add one test as well. For now,
we can only do xml2xml test as qemu command line generation code
is not adapted yet.
  docs/formatdomain.html.in                          | 11 ++++-
  docs/schemas/domaincommon.rng                      |  5 +++
  src/conf/domain_conf.c                             | 15 +++++++
  src/conf/domain_conf.h                             |  1 +
  src/qemu/qemu_domain.c                             | 27 +++++++-----
  tests/qemuxml2argvdata/qemuxml2argv-event_idx.xml  |  2 +-
  .../qemuxml2argv-net-virtio-device.xml             |  2 +-
  .../qemuxml2argvdata/qemuxml2argv-vhost_queues.xml | 51 ++++++++++++++++++++++
  tests/qemuxml2argvdata/qemuxml2argv-virtio-lun.xml |  2 +-
  tests/qemuxml2xmltest.c                            |  1 +
  10 files changed, 103 insertions(+), 14 deletions(-)
  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-vhost_queues.xml

diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 8004428..d671491 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -1990,6 +1990,11 @@
+                <attribute name='queues'>
+                  <ref name="positiveInteger"/>

Should a lower limit be put on it in the RNG? (does qemu have a
documented limit?)
I don't think so. QEMU doesn't have anything documented, but they are
using uint16_t to store the max_queues internally. However, when setting
it in virtio_net_device_init they use:

n->max_queues = MAX(n->nic_conf.queues, 1);

where n->nic_conf.queues is int32_t. Maybe we should ask on the qemu list.

This means we want qemu to either document the limits or expose them
in some manner.

See commit log of 0d70656afded421e434a03c4af4d004a0fbcde47, I was
annoyed about to find out the limits of the various qemu device.


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