Bug 1451978
Summary: | Latest latest virtio driver (network) for Windows drops lots of packets | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Marcus West <mwest> | ||||
Component: | virtio-win | Assignee: | ybendito | ||||
virtio-win sub component: | distribution | QA Contact: | Yu Wang <wyu> | ||||
Status: | CLOSED ERRATA | Docs Contact: | |||||
Severity: | high | ||||||
Priority: | high | CC: | adevolder, ailan, aleksey.kashin, jherrman, lijin, michen, mtessun, mwest, phou, rabraham, wyu, ybendito, yvugenfi | ||||
Version: | 7.3 | ||||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: |
Previously, high packet loss in some cases occurred on Windows guests that use the virtio interface. This update fixes the underlying code, and the affected guests no longer experience the increased packet loss.
|
Story Points: | --- | ||||
Clone Of: | |||||||
: | 1471073 (view as bug list) | Environment: | |||||
Last Closed: | 2018-04-10 06:28:08 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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1471073, 1473046 | ||||||
Attachments: |
|
Description
Marcus West
2017-05-18 04:29:40 UTC
Hi Marcus, Any feedback from customer? Does latest internal build can fix their issue? No updates from the customer, I will check in with them. Hello, I have feedback, the newer drivers a better, but there are still dropped packets. Again, rolling back to the old previously-working drivers reduces packet loss to 0% Hi, On QE side, we ping both same and different subnet hosts , both no timeouts occured. But our env./switch maybe not as complex as yours. since our pings always Average = 1ms . Thanks Yu Wang Created attachment 1291721 [details]
Driver 1 for test and investigation (based on 139)
We assume BADpcap-filter-applied.pcapng is taken simultaneously with logs of the driver (timestamps in pcap file and in driver log are completely different). Pings send in frames (for example) 1, 13, 15, 21, 25, 27 was responded in ~50 ms, responses are valid and correct ICMP packets (all checksums are also correct) but next ping after these frames was sent not after 1 second, but after 5 seconds. This means that respective received ping responses were not delivered to ping application, i.e. lost somewhere on the way. In the logs of the newer driver we see multiple cases when the driver reports checksum error for some packets (non-TCP or UDP) received from host. But there is no report of real checksum verification on these packets. There is some small difference between 110 and 126 for non-IP packets reporting, which should not cause packet loss, but to be on the safe side I'll fix it in custom build and will add more diagnostics to try recognize where the packets are lost. Driver in comment #32 for test. If the same behavior (lost packets) still exist, please make the same record as in comment #22 and in parallel run tmpdump on host, specifying 'icmp' and '-i <tap name>' targeting the tap created for the VM. Additional request: results of 'ethtool -k <tap device>' Fixed in build virtio-win-prewhql-0.1-140 https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=570835 Reproduced this issue with virtio-win-prewhql-139, the result like comment#38, at least 10% of pings timed out. Verified this issue with virtio-win-prewhql-140, the ping flood test, no timeout occurs. Steps as comment#38. Used version: kernel-3.10.0-680.el7.x86_64 qemu-kvm-rhev-2.9.0-14.el7.x86_64 seabios-1.10.2-3.el7.x86_64 change status to verified according to comment#40 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://access.redhat.com/errata/RHBA-2018:0657 |