Description of problem:
when set netkvm parameter "TCP/UDP checksum offload(IPv6)" to the default value as "RX/TX enabled",speed of upload via ipv6 is quite slow.Change value to "Rx enabled" can resolve this issue
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.boot a win2012R2 guest with netkvm:
/usr/libexec/qemu-kvm -name 105NIC2008R2CL4 -enable-kvm -m 4G -smp 4 -uuid 8a45516d-caa5-4f34-940c-ce1b8c86fa7b -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/tmp/105NIC2008R2CL4,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=win2012R2.raw,if=none,id=drive-ide0-0-0,format=raw,serial=mike_cao,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=isa_serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -vga cirrus -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet1,vhost=on,queues=4 -device virtio-net-pc
2.install netkvm driver and keep all parameters as default value
3.install winscp software
4.use winscp uploading a 3G file to host via ipv6
winscp "hostname" field - host ipv6 address
5.set netkvm parameter "TCP/UDP checksum offload(IPv6)" to "RX enabled"
after step4,default value of "TCP/UDP checksum offload(IPv6)" is "RX/TX enabled";
the upload speed is less than 200Kib/s(please check the first attachment),it may take 15+hours to finish uploading,I havn't wait so long to check if upload can be finished correctly.
after step6,"TCP/UDP checksum offload(IPv6) is set to "RX enabled",guest can upload files correctly ,and the speed is about 8000Kib/s(please check the second attachment)
guest can upload files normally via ipv6 when "TCP/UDP checksum offload(IPv6)" is "RX/TX enabled";
Created attachment 1044620 [details]
"tcp/udp checksum offload of ipv6" is "rx/tx enabled"
Created attachment 1044621 [details]
"tcp/udp checksum offload of ipv6" is "rx enabled"
* When you experience the issues is it between VMs on the same host?
I can reproduce it between a Windows VM on Host A and a Linux VM on Host B.
Linux and Windows are not on the same host systems due to licensing.
Between Linux VMs and/or if I download to the Windows VM there is no issue.
Only outbound TCP traffic from the Windows vServer is affected and it only affects IPv6 traffic.
* Can you describe your host network configuration?
Windows VM on Qemu -> tap -> Linux Bridge -> eth (tagged) -> Network -> eth(tagged) -> Linux Bridge -> tap -> Linux VM on Qemu.
* Can provide the output for "ethtool -k” for every NIC (including tap devices) in the host that is involved with the VM that has a problem?
Offload parameters for tap4:
Offload parameters for br136:
Offload parameters for eth2:
* What are the host kernel version, QEMU version and guest driver version you are using?
guest dirver: 0.1.100
I've tried looking and something is going very wrong for me.
I have Windows Server 2012 R2 Build 9600 (installed from DVD iso
I've loaded what I think is the right version of virtio-win from
Windows shows driver version 22.214.171.12400 from 6/3/2015.
When I try to upload a file regardless of IPv4 or IPv6, I see corrupted
LSO packet that is later retransmited, thus resulting in horrible throughput.
If I disable LSO, I get about a 2Gpbs upload speed.
I'll try to hold on to this machine if you want to take a look.
If I had to guess, there might be some kind of checksum interaction issues
when you turn off TX checksum offloading but leave LSO on.
Created attachment 1049571 [details]
ipv6 packet capture
I was able to reproduce the issue with ipv6 traffic, but for me it seems to happen always.
I've attached the tcpdump of the ipv6 traffic. The large TCPv6 segments seem to
be corrupt/truncated. The capture was taken on the vnet1 tap device.
(In reply to Vlad Yasevich from comment #6)
> Created attachment 1049571 [details]
> ipv6 packet capture
> I was able to reproduce the issue with ipv6 traffic, but for me it seems to
> happen always.
> I've attached the tcpdump of the ipv6 traffic. The large TCPv6 segments
> seem to
> be corrupt/truncated. The capture was taken on the vnet1 tap device.
There was a bug in the driver.
should be fixed in build 106 https://brewweb.devel.redhat.com//buildinfo?buildID=448339
wyu,please verify this bug with build106
Reproduced this issue on virtio-win-prewhql-105 version
Verified this issue on virtio-win-prewhql-106 version
Steps same as comment#0
on virtio-win-prewhql-105 (un-fixed version), the issue can be reproduced as comment#0
on virtio-win-prewhql-106 (fix version), guest can upload files normally via ipv6 when "TCP/UDP checksum offload(IPv6)" is "RX/TX enabled"
Base on above, this issue has been fixed already.
Version-Release number of selected component
change status to verified according to comment#12
This bug is fixed in virtio-win-prewhql-0.1-106,but as we discussed,we are not going to push virtio-win-prewhql-0.1-106 in rhel7.2,we push virtio-win-prewhql-0.1-105/110(build110 is also based on build105) instead.
So clear "Fixed In Version" field and this bug will not added into rhel7.2 errata.
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.