Bug 1237024
Summary: | [virtio-win][netkvm]ipv6 uploading speed is quite slow when set "TCP/UDP checksum offload(IPv6)" to "Rx & Tx Enabled" | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | lijin <lijin> | ||||||||
Component: | virtio-win | Assignee: | Yvugenfi <yvugenfi> | ||||||||
virtio-win sub component: | virtio-win-prewhql | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||
Status: | CLOSED ERRATA | Docs Contact: | |||||||||
Severity: | high | ||||||||||
Priority: | high | CC: | jen, lmiksik, pl, vrozenfe, vyasevic, wyu, yvugenfi | ||||||||
Version: | 7.2 | ||||||||||
Target Milestone: | rc | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: |
NO_DOCS
|
Story Points: | --- | ||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2016-11-04 08:47:19 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
lijin
2015-06-30 08:40:07 UTC
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: rx-checksumming: off tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off rx-vlan-offload: off tx-vlan-offload: on ntuple-filters: off receive-hashing: off Offload parameters for br136: rx-checksumming: off tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off rx-vlan-offload: off tx-vlan-offload: on ntuple-filters: off receive-hashing: off 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: off large-receive-offload: off rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off receive-hashing: off * What are the host kernel version, QEMU version and guest driver version you are using? host: 3.13.0-53-generic qemu: 2.2.1 guest dirver: 0.1.100 Interesting... I've tried looking and something is going very wrong for me. I have Windows Server 2012 R2 Build 9600 (installed from DVD iso http://team.virt.bos.redhat.com/microsoft/) I've loaded what I think is the right version of virtio-win from https://brewweb.devel.redhat.com/buildinfo?buildID=438890. Windows shows driver version 62.72.104.10500 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. -vlad 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.
-vlad
(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. > > -vlad 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 Actual Results: 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 virtio-win-prewhql-106 qemu-kvm-rhev-2.3.0-12.el7.x86_64 kernel-3.10.0-296.el7.x86_64 seabios-1.7.5-9.el7.x86_64 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. https://rhn.redhat.com/errata/RHBA-2016-2609.html |