Bug 1272311

*** Bug 1272312 has been marked as a duplicate of this bug. ***

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.

(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?

(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

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

(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.

(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?

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

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.

*** This bug has been marked as a duplicate of bug 1293233 ***

*** This bug has been marked as a duplicate of bug 954261 ***