Description of problem: It shows a really bad performance(approximately 10k/s)when I download a big file via ftp from a kvm guest which enables tso. But it works fine (approx 10M/s) after changing IP address to another subnet(172.18.33.X) In the bad case, almost all ftp-data packets need to be re-transmitted because all first packets have a bad checksum, like this "Checksum: 0x8906 [incorrect, should be 0x8905 (maybe caused by "TCP checksum offload"?)]" Then the ftp client wouldn't send ack to the kvm guest. The following two packets were captured from ftp client: No. Time Source Destination Protocol Info 456 2010-11-01 23:08:25.027685 172.18.36.42 192.168.106.106 FTP-DATA FTP Data: 1448 bytes Frame 456 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 3com_0f:39:0f (00:50:04:0f:39:0f), Dst: Usi_55:6e:f6 (00:16:41:55:6e:f6) Internet Protocol, Src: 172.18.36.42 (172.18.36.42), Dst: 192.168.106.106 (192.168.106.106) Transmission Control Protocol, Src Port: 15319 (15319), Dst Port: 47404 (47404), Seq: 176657, Ack: 1, Len: 1448 Source port: 15319 (15319) Destination port: 47404 (47404) [Stream index: 3] Sequence number: 176657 (relative sequence number) [Next sequence number: 178105 (relative sequence number)] Acknowledgement number: 1 (relative ack number) Header length: 32 bytes Flags: 0x10 (ACK) Window size: 5888 (scaled) Checksum: 0x8906 [incorrect, should be 0x8905 (maybe caused by "TCP checksum offload"?)] Options: (12 bytes) [SEQ/ACK analysis] FTP Data ... No. Time Source Destination Protocol Info 459 2010-11-01 23:08:25.228855 172.18.36.42 192.168.106.106 FTP-DATA [TCP Retransmission] FTP Data: 1448 bytes Frame 459 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: 3com_0f:39:0f (00:50:04:0f:39:0f), Dst: Usi_55:6e:f6 (00:16:41:55:6e:f6) Internet Protocol, Src: 172.18.36.42 (172.18.36.42), Dst: 192.168.106.106 (192.168.106.106) Transmission Control Protocol, Src Port: 15319 (15319), Dst Port: 47404 (47404), Seq: 176657, Ack: 1, Len: 1448 Source port: 15319 (15319) Destination port: 47404 (47404) [Stream index: 3] Sequence number: 176657 (relative sequence number) [Next sequence number: 178105 (relative sequence number)] Acknowledgement number: 1 (relative ack number) Header length: 32 bytes Flags: 0x10 (ACK) Window size: 5888 (scaled) Checksum: 0x883c [correct] Options: (12 bytes) [SEQ/ACK analysis] FTP Data Version-Release number of selected component (if applicable): kvm-83-164.el5 How reproducible: 100% Steps to Reproduce: 1. Set up a kvm guest with e1000 NIC and ip address 172.18.36.42 and enable ftp service 2. Download a big file via ftp from the kvm guest. The ip address of client is 192.168.106.106 Actual results: The speed is about 10k/s. Expected results: The speed should be about 10M/s. Additional info:
Created attachment 456783 [details] Fix the checksum overflow
I have verified that this patch can fix the overflow when adding tcp length to the pseudo-header checksum.
(In reply to comment #2) > I have verified that this patch can fix the overflow when adding tcp length to > the pseudo-header checksum. Mark, the patch looks correct to me. I'll submit it upstream unless you have any interest in doing so.
Alex, please submit the patch. Thanks!
Reproduced this issue kvm-83-163.el5 Steps: 1. boot guest with e1000 nic #/usr/libexec/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -m 4G -smp 2 -monitor stdio -drive file=/root/zhangjunyi/rhel5.6ide.raw,if=ide,boot=on,werror=stop,format=raw -drive file=/root/boot.iso,media=cdrom -fda /usr/share/virtio-win/virtio-drivers-1.0.0-45801-1.0.0.vfd -net nic,vlan=0,macaddr=22:11:22:45:66:83,model=e1000 -net tap,vlan=0,script=/etc/qemu-ifup -uuid `uuidgen` -cpu qemu64,+sse2 -balloon none -boot c -vnc :10 -notify all -boot c 2. enable TSO and setup ftp server in guest #ethtool -K eth0 tso on 1. ethtool -k eth0 Offload parameters for eth0: Cannot get device udp large send offload settings: Operation not supported rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: on udp fragmentation offload: off generic segmentation offload: off generic-receive-offload: off #netstat -a | grep ftp tcp 0 0 tp *: LISTEN #ifconfig eth0 Link encap:Ethernet HWaddr 22:11:22:45:66:83 inet addr:10.66.91.133 Bcast:10.66.91.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:556437 errors:0 dropped:0 overruns:0 frame:0 TX packets:270811 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:672309087 (641.1 MiB) TX bytes:339799714 (324.0 MiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1424 errors:0 dropped:0 overruns:0 frame:0 TX packets:1424 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4216793 (4.0 MiB) TX bytes:4216793 (4.0 MiB) 3.Download a 2 G file via ftp from the kvm guest. The speed is about 9 k/s Verified this issue on kvm-83-208.el5 using the same steps. The speed is 9.7 M/s.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0028.html