From: Alex Williamson <alex.williamson@redhat.com>
To: Thibault VINCENT <thibault.vincent@smartjog.com>
Cc: kvm@vger.kernel.org
Subject: Re: Exceed 1GB/s with virtio-net ?
Date: Thu, 16 Sep 2010 09:01:08 -0600 [thread overview]
Message-ID: <1284649268.23331.490.camel@x201> (raw)
In-Reply-To: <4C8F9F71.8010702@smartjog.com>
On Tue, 2010-09-14 at 18:14 +0200, Thibault VINCENT wrote:
> On 13/09/2010 19:34, Alex Williamson wrote:
> > On Mon, Sep 13, 2010 at 4:32 AM, Thibault VINCENT
> > <thibault.vincent@smartjog.com> wrote:
> >> Hello
> >>
> >> I'm trying to achieve higher than gigabit transferts over a virtio NIC
> >> with no success, and I can't find a recent bug or discussion about such
> >> an issue.
> >>
> >> The simpler test consist of two VM running on a high-end blade server
> >> with 4 cores and 4GB RAM each, and a virtio NIC dedicated to the
> >> inter-VM communication. On the host, the two vnet interfaces are
> >> enslaved into a bridge. I use a combination of 2.6.35 on the host and
> >> 2.6.32 in the VMs.
> >> Running iperf or netperf on these VMs, with TCP or UDP, result in
> >> ~900Mbits/s transferts. This is what could be expected of a 1G
> >> interface, and indeed the e1000 emulation performs similar.
> >>
> >> Changing the txqueuelen, MTU, and offloading settings on every interface
> >> (bridge/tap/virtio_net) didn't improve the speed, nor did the
> >> installation of irqbalance and the increase in CPU and RAM.
> >>
> >> Is this normal ? Is the multiple queue patch intended to address this ?
> >> It's quite possible I missed something :)
> >
> > I'm able to achieve quite a bit more than 1Gbps using virtio-net
> > between 2 guests on the same host connected via an internal bridge.
> > With the virtio-net TX bottom half handler I can easily hit 7Gbps TCP
> > and 10+Gbps UDP using netperf (TCP_STREAM/UDP_STREAM tests). Even
> > without the bottom half patches (not yet in qemu-kvm.git), I can get
> > ~5Gbps. Maybe you could describe your setup further, host details,
> > bridge setup, guests, specific tests, etc... Thanks,
>
> Thanks Alex, I don't use the bottom half patches but anything between
> 3Gbps and 5Gbps would be fine. Here are some more details:
>
> Host
> -----
> Dell M610 ; 2 x Xeon X5650 ; 6 x 8GB
> Debian Squeeze amd64
> qemu-kvm 0.12.5+dfsg-1
> kernel 2.6.35-1 amd64 (Debian Experimental)
>
> Guests
> -------
> Debian Squeeze amd64
> kernel 2.6.35-1 amd64 (Debian Experimental)
>
> To measure the throughput between the guests, I do the following.
>
> On the host:
> * create a bridge
> # brctl addbr br_test
> # ifconfig br_test 1.1.1.1 up
> * start two guests
> # kvm -enable-kvm -m 4096 -smp 4 -drive
> file=/dev/vg/deb0,id=0,boot=on,format=raw -device
> virtio-blk-pci,drive=0,id=0 -device
> virtio-net-pci,vlan=0,id=1,mac=52:54:00:cf:6a:b0 -net
> tap,vlan=0,name=hostnet0
> # kvm -enable-kvm -m 4096 -smp 4 -drive
> file=/dev/vg/deb1,id=0,boot=on,format=raw -device
> virtio-blk-pci,drive=0,id=0 -device
> virtio-net-pci,vlan=0,id=1,mac=52:54:00:cf:6a:b1 -net
> tap,vlan=0,name=hostnet0
> * add guests to the bridge
> # brctl addif br_test tap0
> # brctl addif br_test tap1
>
> On the first guest:
> # ifconfig eth0 1.1.1.2 up
> # iperf -s -i 1
>
> On the second guest:
> # ifconfig eth0 1.1.1.3 up
> # iperf -c 1.1.1.2 -i 1
> ------------------------------------------------------------
> Client connecting to 1.1.1.2, TCP port 5001
> TCP window size: 16.0 KByte (default)
> ------------------------------------------------------------
> [ 3] local 1.1.1.3 port 43510 connected with 1.1.1.2 port 5001
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 80.7 MBytes 677 Mbits/sec
> [ 3] 1.0- 2.0 sec 102 MBytes 855 Mbits/sec
> [ 3] 2.0- 3.0 sec 101 MBytes 847 Mbits/sec
> [ 3] 3.0- 4.0 sec 104 MBytes 873 Mbits/sec
> [ 3] 4.0- 5.0 sec 104 MBytes 874 Mbits/sec
> [ 3] 5.0- 6.0 sec 105 MBytes 881 Mbits/sec
> [ 3] 6.0- 7.0 sec 103 MBytes 862 Mbits/sec
> [ 3] 7.0- 8.0 sec 101 MBytes 848 Mbits/sec
> [ 3] 8.0- 9.0 sec 105 MBytes 878 Mbits/sec
> [ 3] 9.0-10.0 sec 105 MBytes 882 Mbits/sec
> [ 3] 0.0-10.0 sec 1011 MBytes 848 Mbits/sec
>
> On the host again:
> # iperf -c 1.1.1.1 -i 1
> ------------------------------------------------------------
> Client connecting to 1.1.1.1, TCP port 5001
> TCP window size: 16.0 KByte (default)
> ------------------------------------------------------------
> [ 3] local 1.1.1.3 port 60456 connected with 1.1.1.1 port 5001
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 1.0 sec 97.9 MBytes 821 Mbits/sec
> [ 3] 1.0- 2.0 sec 136 MBytes 1.14 Gbits/sec
> [ 3] 2.0- 3.0 sec 153 MBytes 1.28 Gbits/sec
> [ 3] 3.0- 4.0 sec 160 MBytes 1.34 Gbits/sec
> [ 3] 4.0- 5.0 sec 156 MBytes 1.31 Gbits/sec
> [ 3] 5.0- 6.0 sec 122 MBytes 1.02 Gbits/sec
> [ 3] 6.0- 7.0 sec 121 MBytes 1.02 Gbits/sec
> [ 3] 7.0- 8.0 sec 137 MBytes 1.15 Gbits/sec
> [ 3] 8.0- 9.0 sec 139 MBytes 1.17 Gbits/sec
> [ 3] 9.0-10.0 sec 140 MBytes 1.17 Gbits/sec
> [ 3] 0.0-10.0 sec 1.33 GBytes 1.14 Gbits/sec
>
>
> You can see it's quite slow compared to your figures, between the guests
> and with the host too. And there is no specific load on any of the three
> systems, htop in a guest only report one of the four cores going up to
> 70% (sys+user+wait) during the test.
>
> The other tests I mentioned are:
> * iperf or netperf over UDP : maybe 10% faster, no more
> * interface settings : very very few effect
> # ifconfig [br_test,tap0,tap1,eth0] txqueuelen 20000
> # ifconfig eth0 mtu 65534 <-- guest only
> # ethtool -K eth0 gso on <-- guest only
> * double the RAM or number of CPU in the guests, no effect
> * run the two guests on separate hosts, linked with a 10G net, again
> it's exactly the same throughput. I can get >7Gbps between the hosts.
>
> Then I reproduced the test on a completely different system, a desktop
> with Intel i5, 4GB, Debian Squeeze. And unfortunately I get the same
> figures, so the limitation doesn't seem to be hardware bounded.
>
> What's your distro, kernel, and kvm version Alex ? Do you think I need
> to compile qemu with a specific patch or option that may be missing in
> the Squeeze source ?
Do you by chance see better performance if you test a freshly booted
guest with less than 5 minutes of uptime? I see a pretty significant
drop in throughput ramp-up at the 5 minute mark that I haven't been able
to explain. On qemu-kvm, this can keep me below 1Gbps for 1s tests, but
I mostly get up to normal throughput by 10s.
It might be worthwhile for you to build your own qemu-kvm and maybe even
incorporate the bottom half TX patches. These should be in the qemu-kvm
tree whenever the next qemu merge happens (very soon). With those, my
peak throughput is ~3x higher. Also, for best performance pay attention
to cpufreq on the host. You might want to use the performance governor
for testing. You shouldn't need any special configure options for
qemu-kvm.git, I typically only use the --prefix option. Thanks,
Alex
next prev parent reply other threads:[~2010-09-16 15:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-13 10:32 Exceed 1GB/s with virtio-net ? Thibault VINCENT
2010-09-13 17:34 ` Alex Williamson
2010-09-14 16:14 ` Thibault VINCENT
2010-09-16 15:01 ` Alex Williamson [this message]
2010-10-11 20:32 ` matthew.r.rohrer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1284649268.23331.490.camel@x201 \
--to=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=thibault.vincent@smartjog.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox