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
slawek(a)kaplonski.pl
Wiadomość napisana przez Michal Privoznik <mprivozn(a)redhat.com>
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