I'm a little lost in reading the descriptions of the different versions here. Can you confirm the relation between behaviours in the various RHEL5/6/upstream releases is as follows: 

 - Current upstream: Original TX algorithm
 - RHEL6.0 GA: Original TX algorithm
 - RHEL5.4: Original TX algorithm
 - RHEL5.5: Hardcoded to new bottom-half TX algorithm. No access to original algorithm.
 - RHEL6.0 z-stream: Default to new bottom half TX algorithm, configurable to use old original TX algorithm
 - Future upstream. Default to new bottom half TX algorithm, configurable to use old original TX algorithm

(In reply to comment #3)
> I'm a little lost in reading the descriptions of the different versions here.
> Can you confirm the relation between behaviours in the various RHEL5/6/upstream
> releases is as follows: 
> 
>  - Current upstream: Original TX algorithm
>  - RHEL6.0 GA: Original TX algorithm
>  - RHEL5.4: Original TX algorithm
>  - RHEL5.5: Hardcoded to new bottom-half TX algorithm. No access to original
> algorithm.
>  - RHEL6.0 z-stream: Default to new bottom half TX algorithm, configurable to
> use old original TX algorithm
>  - Future upstream. Default to new bottom half TX algorithm, configurable to
> use old original TX algorithm

Almost, the bottom half handler did go out in RHEL5.4, hard coded,
non-configurable.  So RHEL6.0 is the first RHEL instance of the original TX
algorithm.  I think we would feel more comfortable switching the default
without a fallback plan if we were making the change on at least a minor
version boundary rather than z-stream.  However, from a tuning perspective,
it's a worthwhile knob to be able to tweak.

Alex, has this BZ been addressed by your script?  If so, can we resolve it?

(In reply to comment #11)
> Alex, has this BZ been addressed by your script?  If so, can we resolve it?

The script is just a workaround, I think the need still exists.  This problem is going to come up over and over for various devices, so the solution needs to not be specific to virtio-net.

Where is the qemu commandline option for this documented? It isn't in the help output. How can we verify the presence of the option w/o just trying it and having qemu fail?

Also there are now two places where this could exist:

1) as an element inside the <tune> element of the <interface>

2) as an attribute in the <driver name='vhost' .../>

The former is being used to set the size of the sndbuf, the latter is being used to set vhost vs. userland mode for the virtio backend.

It sounds like this should be in the <driver ...> element, since it's specific to virtio.

(In reply to comment #16)
> Where is the qemu commandline option for this documented? It isn't in the help
> output. How can we verify the presence of the option w/o just trying it and
> having qemu fail?

$ /usr/libexec/qemu-kvm -device virtio-net-pci,?
...
virtio-net-pci.tx=string

I think the code is the only place that documents the options are "timer" vs "bh", but it will default to "bh", with an error message, if provided an unknown option

> Also there are now two places where this could exist:
> 
> 1) as an element inside the <tune> element of the <interface>
> 
> 2) as an attribute in the <driver name='vhost' .../>
> 
> The former is being used to set the size of the sndbuf, the latter is being
> used to set vhost vs. userland mode for the virtio backend.
> 
> It sounds like this should be in the <driver ...> element, since it's specific
> to virtio.

Seems reasonable.

selinux-policy package is available on people.redhat.com/dwalsh/SELinux/RHEL6

Is this algorithm setting in upstream qemu as well, or just in RHEL? My F14 box running qemu 0.13.0 doesn't have it...

Yes, this is upstream as well as rhel6.  Should be in f15.

A first (definitely not final) whack at this has been posted upstream. Please take a look at the patch comments and provide feedback:

https://www.redhat.com/archives/libvir-list/2011-February/msg00130.html

The above thread has been updated with a v2 and v3 of the patch. Now just waiting for final ACK and push before a backport can be done.

The fix for this bug has been committed upstream:

  commit b670a41206701f6e1365b83dd5be704864aec9a7
  Author: Laine Stump <laine>
  Date:   Thu Feb 3 13:52:08 2011 -0500
  Subject: Restructure domain struct interface	"driver" data for easier expansion

  commit e9bd5c0e248aaa73db4d26ed4abf27acc6f93cc8
  Author: Laine Stump <laine>
  Date:   Thu Feb 3 15:20:01 2011 -0500
  Subject: Add txmode attribute to interface XML for virtio backend

and a rebased version (nearly pure cherry-pick) posted to rhvirt-patches:

  http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-February/msg01144.html

*** Bug 679676 has been marked as a duplicate of this bug. ***

Verified with the packages below, it's already fixed.
libvirt-0.8.7-8.el6
qemu-kvm-0.12.1.2-2.147.el6


# virsh dumpxml test
...
    <driver txmode='iothread'/>
...

# ps -ef|grep qemu-kvm
... -device virtio-net-pci,tx=bh, ...


# virsh dumpxml test
...
    <driver txmode='timer'/>
...

# ps -ef|grep qemu-kvm
... -device virtio-net-pci,tx=timer, ...

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html