Hello, We found what was the issue there. Our OVS bridge had set datapath_type=NETDEV. Change it to SYSTEM fixed our issue :)
Pozdrawiam / Best regards Sławek Kapłoński [email protected] > Wiadomość napisana przez Sławomir Kapłoński <[email protected]> w dniu > 15.05.2017, o godz. 11:20: > > Hello, > > I have no queue configured on tap and veth devices, quest type is of course > KVM and I’m using virtio model for VM’s NIC. > What we found is that on Xenial (where performance is poor) during test > ovs-vswitchd process is using 100% CPU and there are some messages in ovs > logs: > > 2017-05-12T14:22:04.351Z|00125|poll_loop|INFO|wakeup due to [POLLIN] on fd > 149 (AF_PACKET(tap27903b5e-06)(protocol=0x3)<->) at > ../lib/netdev-linux.c:1139 (86% CPU usage) > > Identical setup (with same versions of ovs, libvirt, gemu and kernel) is > working properly on Trusty. > > Pozdrawiam / Best regards > Sławek Kapłoński > [email protected] > >> Wiadomość napisana przez Michal Privoznik <[email protected]> w dniu >> 15.05.2017, o godz. 08:27: >> >> On 05/12/2017 11:02 AM, Sławomir Kapłoński wrote: >>> Hello, >>> >>> I have some problem with poor network performance on libvirt with qemu and >>> openvswitch. >>> I’m using libvirt 1.3.1, qemu 2.5 and openvswitch 2.6.0 on Ubuntu 16.04 >>> currently. >>> My connection diagram looks like below: >>> >>> >>> +---------------------------+ >>> +---------------------------+ >>> | Net namespace | >>> +------------------+ | OVS bridge | >>> | | >>> | | | | >>> | | >>> | VM | | | >>> | | >>> | | +----+---+ +----+-----+ >>> +----+---+ | >>> | +------+tap dev | | veth A >>> +---------+ veth B | | >>> | | +--------+ +----------+ >>> +--------+ | >>> | iperf >>> -s<---------------------------------------------------------------------------+iperf >>> -c | >>> | | | | >>> | | >>> +------------------+ | | >>> | | >>> | | >>> | | >>> +---------------------------+ >>> +---------------------------+ >>> >>> >>> >>> I haven’t got any QoS in tc configured on any interface. When I do this >>> iperf test I have something about 150Mbps only. IMHO it should be something >>> about 20-30 Gbps there. >> >> There could be a lot of stuff that is suboptimal here. >> Firstly, you should ping your vcpus and guest memory. Then, you might >> want to enable multiqueue for the tap device (that way packet processing >> can be split into multiple vcpus). You also want to make sure, you're >> not overcommitting the host. >> BTW: you may also try setting 'noqueue' qdisc for the tap device (if >> supported by your kernel). Also, the guest is type of KVM, not qemu, >> right? And you're using virtio model for the VM's NIC. >> >> Michal > > > _______________________________________________ > libvirt-users mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/libvirt-users _______________________________________________ libvirt-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvirt-users
