Hide Forgot
Description of problem: Boot up windows2k8 R2 guest ,check offload parameter about tap device on host --- TSO is offload. Version-Release number of selected component (if applicable): qemu-kvm-0.12.1.2-2.246.el6.x86_64 kernel-2.6.32-251.el6.x86_64 virtio-win-prewhql-24 How reproducible: always Steps to Reproduce: 1.Boot up windows2k8 R2 windows guest. /usr/libexec/qemu-kvm -name vm1 -drive file=/usr/local/autotest/tests/kvm/images/win2008r2-64-virtio.raw,index=0,if=none,id=drive-ide0-0-0,media=disk,cache=none,format=raw,aio=native -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -device virtio-net-pci,netdev=idsVdEtL,mac=9a:d9:46:25:27:51,id=ndev00idsVdEtL,bus=pci.0,addr=0x5 -netdev tap,id=idsVdEtL,vhost=on -m 4096 -smp 2,cores=1,threads=1,sockets=2 -cpu Westmere -spice port=8000,disable-ticketing -vga qxl -rtc base=localtime,clock=host,driftfix=slew -boot order=cdn,once=c,menu=off -M rhel6.3.0 -usb -device usb-tablet -enable-kvm -monitor stdio 2.check offload parameter status about nic and tap on host. ethtool -k eth2 ---- 82599EB hardware Offload parameters for eth2: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off ethtool -k tap0 ----windows2k8R2 virtio-win-prewhql-24 Offload parameters for tap0: rx-checksumming: on tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off 3. Actual results: Expected results: virtio-win driver could support tso offload. Additional info: It's not regression one.
Offload settings on TAP device are not mapped one to one on HW device. And in most cases has complementary meaning. For example TSO means that TAP device can transmit large packet - but where it transmit the packet? Into QEMU - so from guest point of view this is a receive side. In case of Windows guest there is no support for receive TCP offload. So current setting make sense.
(In reply to comment #2) > Offload settings on TAP device are not mapped one to one on HW device. And in > most cases has complementary meaning. > For example TSO means that TAP device can transmit large packet - but where it > transmit the packet? Into QEMU - so from guest point of view this is a receive > side. > > In case of Windows guest there is no support for receive TCP offload. So > current setting make sense. Is it possible to supported tso as RFE since it can improve rx performance in windows guests.
(In reply to comment #3) > (In reply to comment #2) > > Offload settings on TAP device are not mapped one to one on HW device. And in > > most cases has complementary meaning. > > For example TSO means that TAP device can transmit large packet - but where it > > transmit the packet? Into QEMU - so from guest point of view this is a receive > > side. > > > > In case of Windows guest there is no support for receive TCP offload. So > > current setting make sense. > > > Is it possible to supported tso as RFE since it can improve rx performance in > windows guests. The luck of support is from Windows OS. If it was possible, we would definitely implement it.
> > Is it possible to supported tso as RFE since it can improve rx performance in > > windows guests. > > The luck of support is from Windows OS. If it was possible, we would definitely > implement it. If so, may I open a separate bug for tracking it ?
(In reply to comment #5) > > > Is it possible to supported tso as RFE since it can improve rx performance in > > > windows guests. > > > > The luck of support is from Windows OS. If it was possible, we would definitely > > implement it. > > If so, may I open a separate bug for tracking it ? It won't make us any good to track Microsoft feature.
RSC (GRO in Linux terms) supported in virtio-win build-57 means tso supported on tap device, from RSC testing results on 2012. We can see significant improvement on RX (guest) throughout as expect. - For 1 RX session, about ~70% improvement. - For 2 RX sessions, about ~170% improvement. - For 4/8 RX sessions, about ~200% improvement. Detail results can be found in attachment. 1. Win2012.64.netperf_win.netperf_exe.best_registry_setting.html. 2. Win2012.64.netperf_win.netperf_exe.default_setting.html
Created attachment 717467 [details] test results with virtio-win-build-57 on 2012 guest under default setting
Created attachment 717468 [details] test results with virtio-win-build-57 on 2012 guest under best registry setting
(In reply to comment #7) > RSC (GRO in Linux terms) supported in virtio-win build-57 means tso > supported on tap device, from RSC testing results on 2012. We can see > significant improvement on RX (guest) throughout as expect. > - For 1 RX session, about ~70% improvement. > - For 2 RX sessions, about ~170% improvement. > - For 4/8 RX sessions, about ~200% improvement. > Detail results can be found in attachment. > 1. Win2012.64.netperf_win.netperf_exe.best_registry_setting.html. > 2. Win2012.64.netperf_win.netperf_exe.default_setting.html RSC on Windows is supported starting from Windows 8/2012 only. Windows Server 2008 R2 kernel doesn't have RSC feature so driver cannot use it. On Windows Server 2012 guest with the latest driver (virtio-win build-57) TSO state on TAP should be on.
*** This bug has been marked as a duplicate of bug 904808 ***