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.
Bug 976732 - send buffer testing fail with multi queue nic on internal host
Summary: send buffer testing fail with multi queue nic on internal host
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: jason wang
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-21 10:19 UTC by Sibiao Luo
Modified: 2013-06-24 12:32 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-24 12:32:39 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Sibiao Luo 2013-06-21 10:19:17 UTC 
Description of problem:
boot up guest with sndbuf=1048576 option for multi queue nic(virtio), then transfer file from guest to internal host(which run QEMU guest) by UDP. The file fail to transfer completed checking the md5 is not the same.

Version-Release number of selected component (if applicable):
host info:
kernel-3.10.0-0.rc5.61.el7.x86_64
qemu-kvm-1.5.0-2.el7.x86_64
guest info:
kernel-3.10.0-0.rc5.61.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot up guest with sndbuf=1048576 option for multi queue nic(virtio).
e.g:# /usr/libexec/qemu-kvm -S -M q35 -cpu SandyBridge -enable-kvm -m 2048 -smp 4...-netdev tap,sndbuf=1048576,id=hostnet0,vhost=on,script=/etc/qemu-ifup,queues=4 -device virtio-net-pci,vectors=9,mq=on,netdev=hostnet0,id=virtio-net-pci0,mac=08:2e:5f:0a:0d:b1,bus=pcie.0,addr=0x5,bootindex=2
2.set all the queues work in guest.
# ethtool -L eth0 combined 4
# ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX:		0
TX:		0
Other:		0
Combined:	4
Current hardware settings:
RX:		0
TX:		0
Other:		0
Combined:	4
3.transfer file from guest to internal host by UDP.
internal) # nc -u -l 1234 > a.out
in guest) # nc -u $internal_host_ip 1234 < a.out
4.check the size and md5 for the file.
# ls -lh a.out 
# md5sum a.out 

Actual results:
after step 4,
guest]# ls -lh a.out 
-rw-r--r--. 1 root root 200M Jun 22 01:00 a.out
guest]# md5sum a.out 
3566de3a97906edb98d004d6b947ae9b  a.out

host]# ls -lh a.out 
-rw-r--r--. 1 root root 200M Jun 21 18:05 a.out
host]# md5sum a.out 
220d6ce1495f02b6ba0eb6d0ba691cd6  a.out

Expected results:
the file transfer completed successfully and check md5 should the same.

Additional info:
If test the sndbuf option without multi queue nic, it have no such issue.
e.g:...-netdev tap,sndbuf=1048576,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=08:2e:5f:0a:0d:b1,bus=pcie.0,addr=0x5,bootindex=2
guest]# ls -lh a.out 
-rw-r--r--. 1 root root 200M Jun 22 01:00 a.out
guest]# md5sum a.out 
3566de3a97906edb98d004d6b947ae9b  a.out

host]# ls -lh a.out
-rw-r--r--. 1 root root 50M Jun 21 18:00 a.out
host]# md5sum a.out 
3566de3a97906edb98d004d6b947ae9b  a.out
Comment 2 Sibiao Luo 2013-06-21 10:27:27 UTC 
(In reply to Sibiao Luo from comment #0)
> 
> How reproducible:
> 100%
always, not 100%.
Comment 3 jason wang 2013-06-21 11:19:23 UTC 
How about tcp? What does ifconfig tap0 in host looks like? How about UDP_STREAM test of netperf?
Comment 4 jason wang 2013-06-21 11:27:23 UTC 
UDP is unreliable, it can't guarantee what you recv is exactly what you send. If you want this reliability, switch to TCP.
Comment 5 Sibiao Luo 2013-06-24 06:13:29 UTC 
(In reply to jason wang from comment #3)
> How about tcp? What does ifconfig tap0 in host looks like? How about
> UDP_STREAM test of netperf?
tcp have no such issue. 
ifconfig tap0 in my host:
# ifconfig tap0
tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::f4f6:e5ff:fef6:8dff  prefixlen 64  scopeid 0x20<link>
        ether f6:f6:e5:f6:8d:ff  txqueuelen 500  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 52  bytes 3871 (3.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
if i use UDP_STREAM test of netperf to external host which have no any package loss.
# netperf -t UDP_STREAM -H $external_host_ip -l 60 -- -m 580
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.66.11.229 (10.66.11.229) port 0 AF_INET : histogram : interval
Socket  Message  Elapsed      Messages                
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

212992     580   60.00     25299447      0    1956.49
229376           60.00     11513042            890.34

(In reply to jason wang from comment #4)
> UDP is unreliable, it can't guarantee what you recv is exactly what you
> send. If you want this reliability, switch to TCP.
Yes, but we have such case, maybe we should modify the it to TCP in TCMS.

Best Regards,
sluo
Comment 6 jason wang 2013-06-24 06:16:18 UTC 
(In reply to Sibiao Luo from comment #5)
> (In reply to jason wang from comment #3)
> > How about tcp? What does ifconfig tap0 in host looks like? How about
> > UDP_STREAM test of netperf?
> tcp have no such issue. 
> ifconfig tap0 in my host:
> # ifconfig tap0
> tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
>         inet6 fe80::f4f6:e5ff:fef6:8dff  prefixlen 64  scopeid 0x20<link>
>         ether f6:f6:e5:f6:8d:ff  txqueuelen 500  (Ethernet)
>         RX packets 0  bytes 0 (0.0 B)
>         RX errors 0  dropped 0  overruns 0  frame 0
>         TX packets 52  bytes 3871 (3.7 KiB)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> if i use UDP_STREAM test of netperf to external host which have no any
> package loss.
> # netperf -t UDP_STREAM -H $external_host_ip -l 60 -- -m 580
> UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 10.66.11.229 (10.66.11.229) port 0 AF_INET : histogram : interval
> Socket  Message  Elapsed      Messages                
> Size    Size     Time         Okay Errors   Throughput
> bytes   bytes    secs            #      #   10^6bits/sec
> 
> 212992     580   60.00     25299447      0    1956.49
> 229376           60.00     11513042            890.34
> 
> (In reply to jason wang from comment #4)
> > UDP is unreliable, it can't guarantee what you recv is exactly what you
> > send. If you want this reliability, switch to TCP.
> Yes, but we have such case, maybe we should modify the it to TCP in TCMS.
> 
> Best Regards,
> sluo

Yes, please do it.
Comment 7 jason wang 2013-06-24 12:32:39 UTC 
Not a bug, closing.
Note You need to log in before you can comment on or make changes to this bug.