Red Hat Bugzilla – 1708120 – Enabling TSO(default value) in guest with e1000e nic, the guest network performance over ipv6 is poor (copy file from guest to host, only reach 2.2MB/s and even lower)
Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Enabling TSO(default value) in guest with e1000e nic, the guest network performance over ipv6 is poor (copy file from guest to host, only reach 2.2MB/s and even lower)
+++ This bug was initially created as a clone of Bug #1708065 +++
Description of problem:
Boot guest with e1000e, then copy a big file from guest to host. The transfer speed is only around 2.2MB/s. However with virtio-net-pci, the transfer speed is around 300MB/s.
guest->host host->guest
e1000e 2.2MB/s 150MB/s
virtio-net-pci 300MB/s 300MB/s
Version-Release number of selected component (if applicable):
4.18.0-82.el8.x86_64
qemu-kvm-2.12.0-70.module+el8.1.0+3165+631e0cd3.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Boot guest with e1000e
-netdev tap,id=hostnet0 \
-device e1000e,netdev=hostnet0,id=net0,mac=fa:5e:07:b4:08:01,bus=root.2 \
2. DD a 4G file in guest
# dd if=/dev/zero of=/root/bigfile oflag=direct bs=1M count=4096
3. Copy this 4G file from guest to host, the speed is much low, only around 2.2MB/s.
# scp -r /root/bigfile root@\[fe80::b3df:567e:33b8:286%ens2\]:/root/
bigfile 1% 44MB 2.2MB/s 31:07 ETA
Actual results:
The transfer speed from guest to host over ipv6 addr is much lower 2MB/s, which is not acceptable.
Expected results:
The transfer speed from guest to host over ipv6 addr should be higher, maybe around 300MB/s.
Additional info:
1. virtio-net-pci works well, it's speed is around 300MB/s.
bigfile 71% 2921MB 305.9MB/s 00:03 ETA
2. With e1000e, copy file from host to guest, the speed is around 150MB/s.
bigfile 39% 1620MB 149.6MB/s 00:16 ETA
Reference:
Full cmd line:
/usr/libexec/qemu-kvm -name rhel8.0 \
-M q35,kernel-irqchip=split \
-cpu host -m 8G \
-smp 4,sockets=1,cores=4,threads=1 \
-device pcie-root-port,id=root.1,slot=1 \
-device pcie-root-port,id=root.2,slot=2 \
-drive file=/home/rhel8.0.qcow2,format=qcow2,if=none,id=drive-virtio-blk0,werror=stop,rerror=stop \
-device virtio-blk-pci,drive=drive-virtio-blk0,id=virtio-blk0,bus=root.1 \
-vnc :2 \
-monitor stdio \
-netdev tap,id=hostnet0 \
-device e1000e,netdev=hostnet0,id=net0,mac=fa:5e:07:b4:08:01,bus=root.2 \
--- Additional comment from jason wang on 2019-05-09 14:02:08 HKT ---
Probably because of a buggy TSO implementation for e1000e. Does disable TSO in guest help? Can you try upstream qemu?
Anyway, very low priority.
Thanks
--- Additional comment from Pei Zhang on 2019-05-09 14:25:39 HKT ---
(In reply to jason wang from comment #1)
> Probably because of a buggy TSO implementation for e1000e. Does disable TSO
> in guest help? Can you try upstream qemu?
Hi Jason,
Thanks for your immediately response.
Disable TSO in guest, the the speed is acceptable, it's 114.6MB/s
# ethtool -K ens2 tso off
# ethtool -k ens2
Features for ens2:
...
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off
...
Thanks,
Pei
> Anyway, very low priority.
>
> Thanks
--- Additional comment from Pei Zhang on 2019-05-09 14:28:48 HKT ---
Additional info(continued):
3. Copy file with e1000e ovs ipv4 addr works well.
guest->host: 174.0MB/s
host->guest: 165.7MB/s
--- Additional comment from Pei Zhang on 2019-05-09 15:07:39 HKT ---
(In reply to Pei Zhang from comment #2)
> (In reply to jason wang from comment #1)
> > Probably because of a buggy TSO implementation for e1000e. Does disable TSO
> > in guest help? Can you try upstream qemu?
Tried upstream qemu: git://git.qemu.org/qemu.git, master branch.
Hit same issue, too.
Keep default TSO on, the speed is around 2MB/s. Disable TSO, the speed is around 110MB/s.
Thanks,
Pei
(In reply to Pei Zhang from comment #1)
> Versions:
> qemu-kvm-3.1.0-24.module+el8.0.1+3117+9f83299e.x86_64
> 4.18.0-80.el8.x86_64
Also hit this issue on 8.1.0 fast train:
4.18.0-82.el8.x86_64
qemu-kvm-4.0.0-0.module+el8.1.0+3169+3c501422.x86_64
So move Version to 8.1. If this bz will also need to be fixed in 8.0.1, let me know please, and I'll clone to 8.0.1. Thanks.
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
Hi Yan
According to comment 6. Can you help me check the following problems? please:
1. In bug 1708065, this bz has been fixed in qemu-kvm-5.2.0-5. Do we plan to fix this bug in qemu-4.2?
2. I tried the test 20 times in the latest qemu package - "qemu-kvm-4.2.0-45.module+el8.4.0+9900+483536ed.x86_64"，this problem was not reproduced. But I reproduced this problem in qemu-kvm-4.2.0-40.module+el8.4.0+9278+dd53883d.x86_64. Can you help check if this problem has been fixed in the latest qemu-4.2?
3. If it cannot be fixed on RHEL8.4-Virt(qemu-4.2), should the stale date be reset? Thanks in advance.
Best Regards
Lei
Comment 8Yvugenfi@redhat.com
2021-02-23 09:16:22 UTC
(In reply to Lei Yang from comment #7)
> Hi Yan
>
> According to comment 6. Can you help me check the following problems? please:
> 1. In bug 1708065, this bz has been fixed in qemu-kvm-5.2.0-5. Do we plan to
> fix this bug in qemu-4.2?
> 2. I tried the test 20 times in the latest qemu package -
> "qemu-kvm-4.2.0-45.module+el8.4.0+9900+483536ed.x86_64"，this problem was not
> reproduced. But I reproduced this problem in
> qemu-kvm-4.2.0-40.module+el8.4.0+9278+dd53883d.x86_64. Can you help check if
> this problem has been fixed in the latest qemu-4.2?
> 3. If it cannot be fixed on RHEL8.4-Virt(qemu-4.2), should the stale date be
> reset? Thanks in advance.
>
> Best Regards
> Lei
Hello Lei,
My answers:
1. We didn't have special plans to fix this BZ in 4.2
2. I will take a look
3. If we didn't plan to fix it in 4.2, not sure there is a need in cloned BZ.
Best regards,
Yan.
Comment 9Yvugenfi@redhat.com
2021-02-24 13:02:07 UTC
(In reply to Yan Vugenfirer from comment #8)
> (In reply to Lei Yang from comment #7)
> > Hi Yan
> >
> > According to comment 6. Can you help me check the following problems? please:
> > 1. In bug 1708065, this bz has been fixed in qemu-kvm-5.2.0-5. Do we plan to
> > fix this bug in qemu-4.2?
> > 2. I tried the test 20 times in the latest qemu package -
> > "qemu-kvm-4.2.0-45.module+el8.4.0+9900+483536ed.x86_64"，this problem was not
> > reproduced. But I reproduced this problem in
> > qemu-kvm-4.2.0-40.module+el8.4.0+9278+dd53883d.x86_64. Can you help check if
> > this problem has been fixed in the latest qemu-4.2?
> > 3. If it cannot be fixed on RHEL8.4-Virt(qemu-4.2), should the stale date be
> > reset? Thanks in advance.
> >
> > Best Regards
> > Lei
>
> Hello Lei,
>
> My answers:
> 1. We didn't have special plans to fix this BZ in 4.2
> 2. I will take a look
> 3. If we didn't plan to fix it in 4.2, not sure there is a need in cloned BZ.
>
> Best regards,
> Yan.
Hello Lei,
Regarding the differences between the versions, I don't see in the downstream patches that are applied on top of 4.2 any fixes related to the segmentation offload with IPv6.
Best regards,
Yan.
Comment 10RHEL Program Management
2021-03-15 07:35:55 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
The same issue has been fixed on RHEL8.4-AV(trigger through bz1708065), and also based on comment 8, no plan to fix on RHEL8.4-Virt. So agree to close it 'WONTFIX'