[libvirt] [PATCH 4/5] conf: add options for disabling segment offloading

[Ján Tomko]

On 09/16/2014 12:24 AM, John Ferlan wrote:
> 
> 
> On 09/11/2014 07:43 AM, Ján Tomko wrote:
>> Add the following attributes:
>> csum, gso, guest_tso4, guest_tso6, guest_ecn
>> to the <driver> element of network interface
>> which control the virtio-net device properties
>> of the same names.
>> ---
>>  docs/formatdomain.html.in                          | 27 ++++++++
>>  docs/schemas/domaincommon.rng                      | 25 +++++++
>>  src/conf/domain_conf.c                             | 81 ++++++++++++++++++++++
>>  src/conf/domain_conf.h                             |  5 ++
>>  .../qemuxml2argv-net-virtio-disable-offloads.xml   | 32 +++++++++
>>  tests/qemuxml2xmltest.c                            |  1 +
>>  6 files changed, 171 insertions(+)
>>  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-virtio-disable-offloads.xml
>>
>> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
>> index a2ea758..5b2758a 100644
>> --- a/docs/formatdomain.html.in
>> +++ b/docs/formatdomain.html.in
>> @@ -3847,6 +3847,12 @@ qemu-kvm -net nic,model=? /dev/null
>>        <model type='virtio'/>
>>        <b><driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='off' queues='5'/></b>
>>      </interface>
>> +    <interface type='network'>
>> +      <source network='default'/>
>> +      <target dev='vnet2'/>
>> +      <model type='virtio'/>
>> +      <b><driver csum='off' gso='off' guest_tso4='off' guest_tso6='off' guest_ecn='off'/></b>
>> +    </interface>
> 
> This doesn't require a driver name='' value?
> 

AFAIK only queues require name='vhost'.

>>    </devices>
>>    ...</pre>
>>  
>> @@ -3949,6 +3955,27 @@ qemu-kvm -net nic,model=? /dev/null
>>          processor, resulting in much higher throughput.
>>          <span class="since">Since 1.0.6 (QEMU and KVM only)</span>
>>        </dd>
>> +      <dt><code>csum</code></dt>
>> +      <dd>
>> +        The <code>csum</code> attribute with possible values <code>on</code>
>> +        and <code>off</code> controls host-side support for packets with
>> +        partial checksum values.
>> +        <span class="since">Since 1.2.9 (QEMU only)</span><br/><br/>
>> +
>> +        <b>In general you should leave this option alone, unless you
>> +        are very certain you know what you are doing.</b>
>> +      </dd>
>> +      <dt>segment offloading options</dt>
>> +      <dd>
>> +        The attributes <code>gso</code>, <code>guest_tso4</code>,
>> +        <code>guest_tso6</code>, <code>guest_ecn</code> with possible
>> +        values of <code>on</code> and <code>off</code> can be used
>> +        to tune segment offloading.
>> +        <span class="since">Since 1.2.9 (QEMU only)</span><br/><br/>
>> +
>> +        <b>In general you should leave this option alone, unless you
>> +        are very certain you know what you are doing.</b>
> 
> s/this option/these options/
> 
> [oh - I'm having a flashback to something similar I had to do at my
> former employer with their virtualization switch software...  these got
> enabled by some application and caused shall we say significant
> performance issues, especially for older drivers.  That particular
> software was loaded/started after the virtualization network switch and
> thus reset what our code had done... Bugger to find as it embedded in
> some output from some network command that was executed rarely in our
> vswitch network daemon layer]
> 
> Anyway, I understand it's desired to not say much about them, but is
> there any need to say what the defaults are? Furthermore, does one
> domain's setting affect other domains?  I guess my curiosity is more is
> this a domain function or an interface (host) setting. We may want to
> indicate that here... Is the difference dependent upon the driver name?
> 

This is a per (guest) interface setting, I'm not aware of it affecting other
interfaces or domains. Perhaps the 'leave this option alone' was too harsh.
I'll add the defaults before pushing/sending another version.

Jan

> I know from my previous experience it had a wider affect, but that code
> had a very different implementation. The vswitch was separate from the
> guest as a host process to which guests could configure ports. The
> vswitch software had the configuration magic to the lower level network
> driver(s) which is where the tso/cko, etc. were managed in the kernel.
> The equivalent of 'em0', 'eth0', etc - the physical NIC. A vswitch was
> "tied" to a particular physical NIC. So any changes to the pNIC cast a
> wide net, which is why "other" software setting TSO/CKO options on the
> same pNIC our vswitch used after our code disabled it caused all sorts
> of issues.  (Just so you understand why I'm asking the question).
> 
>> +      </dd>
>>      </dl>
>>  
>>      <h5><a name="elementsNICSTargetOverride">Overriding the target element</a></h5>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140917/139df76b/attachment-0001.sig>