All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.