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 1272311 - Without vhost=on, during netperf w/ protocol UDP_STREAM in guest, this guest can not response other thing
Summary: Without vhost=on, during netperf w/ protocol UDP_STREAM in guest, this guest ...
Keywords:
Status: CLOSED DUPLICATE of bug 954261
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: jason wang
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 1272312 (view as bug list)
Depends On: 962733 1272312
Blocks: 962749
TreeView+ depends on / blocked
 
Reported: 2015-10-16 03:34 UTC by weliao
Modified: 2016-07-04 02:51 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 962733
Environment:
Last Closed: 2016-07-04 02:40:39 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Comment 2 weliao 2015-10-16 04:33:48 UTC 
*** Bug 1272312 has been marked as a duplicate of this bug. ***
Comment 3 jason wang 2015-10-16 07:48:02 UTC 
What's the qdisc used in host? Need to use something which can have fair queueing. E.g sfq or others.

Suspect a duplication of https://bugzilla.redhat.com/show_bug.cgi?id=955540. A known issue. The solution is using enabling tx interrupt in guest.
Comment 4 jason wang 2015-10-16 07:54:33 UTC 
(In reply to jason wang from comment #3)
> What's the qdisc used in host? Need to use something which can have fair
> queueing. E.g sfq or others.
> 
> Suspect a duplication of https://bugzilla.redhat.com/show_bug.cgi?id=955540.
> A known issue. The solution is using enabling tx interrupt in guest.

Ok, speak too fast. You see the issue if vhost=off? Need your virtio-net part of info qtree. Does it work if you're using tx=timer?
Comment 5 weliao 2015-10-16 09:25:09 UTC 
(In reply to jason wang from comment #3)
> What's the qdisc used in host? Need to use something which can have fair
> queueing. E.g sfq or others.
> 
> Suspect a duplication of https://bugzilla.redhat.com/show_bug.cgi?id=955540.
> A known issue. The solution is using enabling tx interrupt in guest.

[root@dhcp-8-118 home]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP mode DEFAULT qlen 1000
    link/ether 24:be:05:0c:1e:92 brd ff:ff:ff:ff:ff:ff
3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT 
    link/ether 82:5c:83:46:ae:3c brd ff:ff:ff:ff:ff:ff
4: pri-ovs1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT 
    link/ether 4a:4a:a9:97:b5:4a brd ff:ff:ff:ff:ff:ff
5: ovs0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/ether 24:be:05:0c:1e:92 brd ff:ff:ff:ff:ff:ff
6: privatebr: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT 
    link/ether fe:b5:f8:03:87:48 brd ff:ff:ff:ff:ff:ff
7: pri-ovs0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT 
    link/ether 1a:71:96:6e:fa:42 brd ff:ff:ff:ff:ff:ff
8: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT 
    link/ether 52:54:00:e3:d7:db brd ff:ff:ff:ff:ff:ff
9: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT qlen 500
    link/ether 52:54:00:e3:d7:db brd ff:ff:ff:ff:ff:ff
24: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UNKNOWN mode DEFAULT qlen 500
    link/ether 0e:13:04:7c:40:66 brd ff:ff:ff:ff:ff:ff

Ok, speak too fast. You see the issue if vhost=off? Need your virtio-net part of info qtree. Does it work if you're using tx=timer?
      dev: virtio-net-pci, id "net0"
        ioeventfd = false
        vectors = 3 (0x3)
        virtio-pci-bus-master-bug-migration = false
        disable-legacy = false
        disable-modern = true
        addr = 03.0
        romfile = "pxe-virtio.rom"
        rombar = 1 (0x1)
        multifunction = false
        command_serr_enable = true
        class Ethernet controller, addr 00:03.0, pci id 1af4:1000 (sub 1af4:0001)
        bar 0: i/o at 0xffffffffffffffff [0x1e]
        bar 1: mem at 0xffffffffffffffff [0xffe]
        bar 6: mem at 0xffffffffffffffff [0x3fffe]
        bus: virtio-bus
          type virtio-pci-bus
          dev: virtio-net-device, id ""
            csum = true
            guest_csum = true
            gso = true
            guest_tso4 = true
            guest_tso6 = true
            guest_ecn = true
            guest_ufo = true
            guest_announce = true
            host_tso4 = true
            host_tso6 = true
            host_ecn = true
            host_ufo = true
            mrg_rxbuf = true
            status = true
            ctrl_vq = true
            ctrl_rx = true
            ctrl_vlan = true
            ctrl_rx_extra = true
            ctrl_mac_addr = true
            ctrl_guest_offloads = true
            mq = false
            mac = "52:54:00:0b:06:81"
            vlan = <null>
            netdev = "hostnet0"
            x-txtimer = 150000 (0x249f0)
            x-txburst = 256 (0x100)
            tx = ""
            indirect_desc = true
            event_idx = true
            notify_on_empty = true
            any_layout = true
Comment 6 jason wang 2015-10-20 05:02:08 UTC 
So you've already used tx timer? How about tx bh? Is this a regression? If yes, can you bisect to find the first bad commit. If not, can you reproduce this issue on upstream qemu.git?

Thanks
Comment 7 weliao 2015-10-21 09:06:33 UTC 
(In reply to jason wang from comment #6)
> So you've already used tx timer? How about tx bh? Is this a regression? If
> yes, can you bisect to find the first bad commit. If not, can you reproduce
> this issue on upstream qemu.git?
> 
> Thanks

if tx = "bh", has this issue too, 
retest on qemu-kvm-rhev-2.3.0-2.el7.x86_64, still has this issue,So it is not a regression bz.
Comment 8 jason wang 2015-10-22 03:08:39 UTC 
(In reply to weliao from comment #7)
> (In reply to jason wang from comment #6)
> > So you've already used tx timer? How about tx bh? Is this a regression? If
> > yes, can you bisect to find the first bad commit. If not, can you reproduce
> > this issue on upstream qemu.git?
> > 
> > Thanks
> 
> if tx = "bh", has this issue too, 
> retest on qemu-kvm-rhev-2.3.0-2.el7.x86_64, still has this issue,So it is
> not a regression bz.

The question was answered partially. Can you reproduce this on upstream qemu.git?
Comment 9 jason wang 2015-10-22 06:24:04 UTC 
Could not reproduce the issue. Needs:

- tc qdisc show in both host and guest
- brctl show in host
- use simple cli, e.g just keep network and disk and remove all other devices to see it the problem still.

Thanks
Comment 10 weliao 2015-10-23 06:36:44 UTC 
Host:
[root@dhcp-8-139 home]# tc qdisc show
qdisc pfifo_fast 0: dev eno1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev virbr0-nic root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev tap0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
[root@dhcp-8-118 qemu-kvm]# ovs-vsctl show
d888d2ed-3336-4429-98f7-0b922604cb70
    Bridge "ovs0"
        Port "ovs0"
            Interface "ovs0"
                type: internal
        Port "tap0"
            Interface "tap0"
        Port "eno1"
            Interface "eno1"
    ovs_version: "2.4.0"
Guest:
[root@dhcp-9-25 home]# tc qdisc show
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev virbr0-nic root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

(In reply to jason wang from comment #8)
> (In reply to weliao from comment #7)
> > (In reply to jason wang from comment #6)
> > > So you've already used tx timer? How about tx bh? Is this a regression? If
> > > yes, can you bisect to find the first bad commit. If not, can you reproduce
> > > this issue on upstream qemu.git?
> > > 
> > > Thanks
> > 
> > if tx = "bh", has this issue too, 
> > retest on qemu-kvm-rhev-2.3.0-2.el7.x86_64, still has this issue,So it is
> > not a regression bz.
> 
> The question was answered partially. Can you reproduce this on upstream
> qemu.git?
qemu-system-x86_64 -name guest1 -S -machine pc,accel=kvm,usb=off -cpu SandyBridge -m 4G  -smp 4 -drive file=/home/rhel7.2.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0 -boot menu=on  -netdev tap,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown,id=hostnet0,vhost=off -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0b:06:81,bus=pci.0,addr=0x3   -monitor stdio -qmp tcp:0:4444,server,nowait -vnc 0.0.0.0:1 -L /usr/share/seabios/ -bios bios-256k.bin
yes, can reproduce this issue on upstream qemu.git.
Comment 11 jason wang 2016-07-04 02:40:39 UTC 

*** This bug has been marked as a duplicate of bug 1293233 ***
Comment 12 jason wang 2016-07-04 02:51:00 UTC 

*** This bug has been marked as a duplicate of bug 954261 ***
Note You need to log in before you can comment on or make changes to this bug.