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>
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list