[libvirt] [PATCH for 3.7.0] docs: Document yet another limitation of tx_queue_size
https://bugzilla.redhat.com/show_bug.cgi?id=1484234 Turns out, only vhostuser type of interfaces are supported currently. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- I'd like to get this one in since the whole feature is being introduced in this release. docs/formatdomain.html.in | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 19e869f12..8ca7637a4 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -5213,7 +5213,10 @@ qemu-kvm -net nic,model=? /dev/null The default value is hypervisor dependent and may change across its releases. Moreover, some hypervisors may pose some restrictions on actual value. For instance, QEMU - v2.9 requires value to be a power of two from [256, 1024] range. + v2.9 requires value to be a power of two from [256, 1024] + range. In addition to that, this may work only for a subset of + interface types, e.g. aforementioned QEMU enables this option + only for <code>vhostuser</code> type. <span class="since">Since 3.7.0 (QEMU and KVM only)</span><br/><br/> <b>In general you should leave this option alone, unless you -- 2.13.5
On Tue, Aug 29, 2017 at 17:05:23 +0200, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1484234
Turns out, only vhostuser type of interfaces are supported currently.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> ---
I'd like to get this one in since the whole feature is being introduced in this release.
docs/formatdomain.html.in | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 19e869f12..8ca7637a4 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -5213,7 +5213,10 @@ qemu-kvm -net nic,model=? /dev/null The default value is hypervisor dependent and may change across its releases. Moreover, some hypervisors may pose some restrictions on actual value. For instance, QEMU - v2.9 requires value to be a power of two from [256, 1024] range. + v2.9 requires value to be a power of two from [256, 1024] + range. In addition to that, this may work only for a subset of + interface types, e.g. aforementioned QEMU enables this option + only for <code>vhostuser</code> type. <span class="since">Since 3.7.0 (QEMU and KVM only)</span><br/><br/>
<b>In general you should leave this option alone, unless you
So it's getting even more riddiculous. I should have NACKed the feature. ACK, safe for freeze.
On 08/30/2017 10:03 AM, Peter Krempa wrote:
On Tue, Aug 29, 2017 at 17:05:23 +0200, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1484234
Turns out, only vhostuser type of interfaces are supported currently.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> ---
I'd like to get this one in since the whole feature is being introduced in this release.
docs/formatdomain.html.in | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 19e869f12..8ca7637a4 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -5213,7 +5213,10 @@ qemu-kvm -net nic,model=? /dev/null The default value is hypervisor dependent and may change across its releases. Moreover, some hypervisors may pose some restrictions on actual value. For instance, QEMU - v2.9 requires value to be a power of two from [256, 1024] range. + v2.9 requires value to be a power of two from [256, 1024] + range. In addition to that, this may work only for a subset of + interface types, e.g. aforementioned QEMU enables this option + only for <code>vhostuser</code> type. <span class="since">Since 3.7.0 (QEMU and KVM only)</span><br/><br/>
<b>In general you should leave this option alone, unless you
So it's getting even more riddiculous. I should have NACKed the feature.
Why ridiculous? Some features work only for some devices. By the same token, some features work only for some hypervisors if you see where I'm going.
ACK, safe for freeze.
Thanks, pushed. Michal
On Wed, Aug 30, 2017 at 10:18:17 +0200, Michal Privoznik wrote:
On 08/30/2017 10:03 AM, Peter Krempa wrote:
On Tue, Aug 29, 2017 at 17:05:23 +0200, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1484234
Turns out, only vhostuser type of interfaces are supported currently.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> ---
I'd like to get this one in since the whole feature is being introduced in this release.
docs/formatdomain.html.in | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 19e869f12..8ca7637a4 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -5213,7 +5213,10 @@ qemu-kvm -net nic,model=? /dev/null The default value is hypervisor dependent and may change across its releases. Moreover, some hypervisors may pose some restrictions on actual value. For instance, QEMU - v2.9 requires value to be a power of two from [256, 1024] range. + v2.9 requires value to be a power of two from [256, 1024] + range. In addition to that, this may work only for a subset of + interface types, e.g. aforementioned QEMU enables this option + only for <code>vhostuser</code> type. <span class="since">Since 3.7.0 (QEMU and KVM only)</span><br/><br/>
<b>In general you should leave this option alone, unless you
So it's getting even more riddiculous. I should have NACKed the feature.
Why ridiculous? Some features work only for some devices. By the same token, some features work only for some hypervisors if you see where I'm going.
Ridiculous is the fact, that the documentation blob only states when it does not work, which also apparently was incomplete, while there is no absolutely no guidance on how to set it up. These facts were deemed enough to reject a feature.
On 08/30/2017 10:23 AM, Peter Krempa wrote:
On Wed, Aug 30, 2017 at 10:18:17 +0200, Michal Privoznik wrote:
On 08/30/2017 10:03 AM, Peter Krempa wrote:
On Tue, Aug 29, 2017 at 17:05:23 +0200, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1484234
Turns out, only vhostuser type of interfaces are supported currently.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> ---
I'd like to get this one in since the whole feature is being introduced in this release.
docs/formatdomain.html.in | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 19e869f12..8ca7637a4 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -5213,7 +5213,10 @@ qemu-kvm -net nic,model=? /dev/null The default value is hypervisor dependent and may change across its releases. Moreover, some hypervisors may pose some restrictions on actual value. For instance, QEMU - v2.9 requires value to be a power of two from [256, 1024] range. + v2.9 requires value to be a power of two from [256, 1024] + range. In addition to that, this may work only for a subset of + interface types, e.g. aforementioned QEMU enables this option + only for <code>vhostuser</code> type. <span class="since">Since 3.7.0 (QEMU and KVM only)</span><br/><br/>
<b>In general you should leave this option alone, unless you
So it's getting even more riddiculous. I should have NACKed the feature.
Why ridiculous? Some features work only for some devices. By the same token, some features work only for some hypervisors if you see where I'm going.
Ridiculous is the fact, that the documentation blob only states when it does not work, which also apparently was incomplete, while there is no absolutely no guidance on how to set it up.
Isn't that true for all of our documentation? I don't see explained why users should turn KVM on, and how does KVM work under the hood. We just merely say "domain element can have an attribute 'type' which can have the following values: kvm, qemu, kqemu (!), xen ..." By the same token, this is also ridiculous. Or any other elements/attributes that say "this is hypervisor specific". Also, this is an option for fine tuning performance of some specific guests. And like with most performance tuning, there's no "higher is better" or "lower is better" approach. It strongly depends on the use case. Therefore we should not give any advice. Michal
participants (2)
-
Michal Privoznik -
Peter Krempa