Patches proposed on the upstream list:

https://www.redhat.com/archives/libvir-list/2016-August/msg00960.html

v2 posted here:

https://www.redhat.com/archives/libvir-list/2016-August/msg01327.html

they are in Jason's net tree, -next branch. You can use that as the
upstream since that is not rebased.

Moving to POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2016-September/msg00259.html

Scratch build:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=11730947

Test on upstream libvirt-2.3.0-1.el7.x86_64, 
qemu-kvm-rhev-2.6.0-22.el7.x86_64 

1. negative test, define the rx_queue_size to some negative ones, PASS.

2. migration test, 1）migrate during the guest is copying a big file with rx_queue_size defined(libvirt-2.3.0->libvirt-2.3.0), then migrate back, PASS;

2) migrate with rx_queue_size defined from libvirt-2.3.0->libvirt-2.0.8, then migrate back, need confirm.

3. hotplug,PASS


1. negative test
1) Define the rx_queue_size to 128,2048, the xml can be validated, but guest can not start
# virsh start s1
error: Failed to start domain s1
error: internal error: process exited while connecting to monitor: 2016-09-14T01:32:04.248922Z qemu-kvm: -device virtio-net-pci,mq=on,vectors=12,rx_queue_size=128,netdev=hostnet0,id=net0,mac=52:54:00:9f:5a:eb,bus=pci.0,addr=0x3: Invalid rx_queue_size (= 128), must be a power of 2 between 256 and 1024.

2)define the rx_queue_size to 555,and other character like 'ss', '-3', the xml can not be validated
# virsh edit s1  ====> edit the rx_queue_size to 555
error: unsupported configuration: rx_queue_size has to be a power of two
Failed. Try again? [y,n,i,f,?]: 

3) try 256, 512 and 1024, the guest can start successfully.
# ps -aux | grep  qemu-kvm-rhev
...
-netdev tap,fds=27:29:30:31:32,id=hostnet0,vhost=on,vhostfds=33:34:35:36:37 -device virtio-net-pci,mq=on,vectors=12,rx_queue_size=1024,netdev=hostnet0,id=net0,mac=52:54:00:9f:5a:eb,bus=pci.0,addr=0x3
...
on the guest,check
# ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:        *1024*
RX Mini:    0
RX Jumbo:    0
TX:        256
Current hardware settings:
RX:        *1024*
RX Mini:    0
RX Jumbo:    0
TX:        256

2. migration test (test 256,512 and 1024)
1) set the rx_queue_size as 1024, start the guest and copy a big file to the guest.
on the guest
# scp work:/home/Downloads/rhel7.2.iso  ./
during the copy process, do migration
# virsh migrate s1 --live qemu+ssh://server/system --verbose
root@server's password:
Migration: [100%]
And migrate back.

2) for libvirt-2.3.0 ->libvirt-2.0.8, the "rx_queue_size" will be ignored on the target which do not support this attribute.
Set the rx_queue_size to 1024 on the src host. 
After migration, check on target host:
# virsh dumpxml s1 | grep /interface -B8
    <interface type='network'>
....
      <model type='virtio'/>
      <driver name='vhost' queues='5'/> ====> the rx_queue_size will be ignored
.....
    </interface>

# ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:		1024 
RX Mini:	0
RX Jumbo:	0
TX:		256
Current hardware settings:
RX:		1024   =====> on the guest, the rx queue size is still 1024
RX Mini:	0
RX Jumbo:	0
TX:		256

# ps aux | grep qemu-kvm
-netdev tap,fds=26:28:29:30:31,id=hostnet0,vhost=on,vhostfds=32:33:34:35:36 -device virtio-net-pci,mq=on,vectors=12,netdev=hostnet0,id=net0,mac=52:54:00:9f:5a:eb,bus=pci.0,addr=0x3
====> the rx_queue_size=1024 is ignored.

Please help to confirm it this is expected, if it is backward compatible?

3. 
# cat inter
   <interface type='network'>
      <source network='default'/>
      <model type='virtio'/>
      <driver name='vhost' queues='5' rx_queue_size='1024'/>
    </interface>
# virsh attach-device s1 inter --config --live
Device attached successfully

If these test scenarios enough? 
If it is necessary to test the bridge/macvtap type interface as well?
Please help to give some suggestions, thank you.

(In reply to yalzhang from comment #19)
> Test on upstream libvirt-2.3.0-1.el7.x86_64, 
> qemu-kvm-rhev-2.6.0-22.el7.x86_64 
> 

> 2) for libvirt-2.3.0 ->libvirt-2.0.8, the "rx_queue_size" will be ignored on
> the target which do not support this attribute.
> Set the rx_queue_size to 1024 on the src host. 
> After migration, check on target host:
> # virsh dumpxml s1 | grep /interface -B8
>     <interface type='network'>
> ....
>       <model type='virtio'/>
>       <driver name='vhost' queues='5'/> ====> the rx_queue_size will be
> ignored
> .....
>     </interface>
> 
> # ethtool -g eth0
> Ring parameters for eth0:
> Pre-set maximums:
> RX:		1024 
> RX Mini:	0
> RX Jumbo:	0
> TX:		256
> Current hardware settings:
> RX:		1024   =====> on the guest, the rx queue size is still 1024
> RX Mini:	0
> RX Jumbo:	0
> TX:		256
> 
> # ps aux | grep qemu-kvm
> -netdev tap,fds=26:28:29:30:31,id=hostnet0,vhost=on,vhostfds=32:33:34:35:36
> -device
> virtio-net-pci,mq=on,vectors=12,netdev=hostnet0,id=net0,mac=52:54:00:9f:5a:
> eb,bus=pci.0,addr=0x3
> ====> the rx_queue_size=1024 is ignored.
> 
> Please help to confirm it this is expected, if it is backward compatible?

Yes, this is expected. I mean, it would be a bug if libvirt was forward compatible (which it is not). The only other option we have is to forbid migration to older libvirt because some piece of information would be lost otherwise. We just have to live with it.

> 

> If these test scenarios enough? 
> If it is necessary to test the bridge/macvtap type interface as well?
> Please help to give some suggestions, thank you.

Yes, this is very extensive testing. Thank you!

move the bug to verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2577.html