[libvirt] [PATCH for 3.7.0] docs: Document yet another limitation of tx_queue_size

[Michal Privoznik]

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 at 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