All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: David Ahern <dsahern@gmail.com>
Cc: KVM mailing list <kvm@vger.kernel.org>
Subject: Re: performance of virtual functions compared to virtio
Date: Mon, 25 Apr 2011 12:13:13 -0600	[thread overview]
Message-ID: <1303755193.3431.50.camel@x201> (raw)
In-Reply-To: <4DB5B1C4.4000602@gmail.com>

On Mon, 2011-04-25 at 11:39 -0600, David Ahern wrote:
> On 04/20/11 20:35, Alex Williamson wrote:
> > Device assignment via a VF provides the lowest latency and most
> > bandwidth for *getting data off the host system*, though virtio/vhost is
> > getting better.  If all you care about is VM-VM on the same host or
> > VM-host, then virtio is only limited by memory bandwidth/latency and
> > host processor cycles.  Your processor has 25GB/s of memory bandwidth.
> > On the other hand, the VF has to send data all the way out to the wire
> > and all the way back up through the NIC to get to the other VM/host.
> > You're using a 1Gb/s NIC.  Your results actually seem to indicate you're
> > getting better than wire rate, so maybe you're only passing through an
> > internal switch on the NIC, in any case, VFs are not optimal for
> > communication within the same physical system.  They are optimal for off
> > host communication.  Thanks,
> 
> Hi Alex:
> 
> Host-host was the next focus for the tests. I have 2 of the
> aforementioned servers, each configured identically. As a reminder:
> 
> Host:
>   Dell R410
>   2 quad core E5620@2.40 GHz processors
>   16 GB RAM
>   Intel 82576 NIC (Gigabit ET Quad Port)
>   - devices eth2, eth3, eth4, eth5
>   Fedora 14
>   kernel: 2.6.35.12-88.fc14.x86_64
>   qemu-kvm.git, ffce28fe6 (18-April-11)
> 
> VMs:
>   Fedora 14
>   kernel 2.6.35.11-83.fc14.x86_64
>   2 vcpus
>   1GB RAM
>   2 NICs - 1 virtio, 1 VF
> 
> The virtio network arguments to qemu-kvm are:
>   -netdev type=tap,vhost=on,ifname=tap0,id=netdev1
>   -device virtio-net-pci,mac=${mac},netdev=netdev1
> 
> 
> For this round of tests I have the following setup:
> 
>   .======================================.
>   | Host - A                             |
>   |                                      |
>   |      .-------------------------.     |
>   |      |  Virtual Machine - C    |     |
>   |      |                         |     |
>   |      |  .------.     .------.  |     |
>   |      '--| eth1 |-----| eth0 |--'     |
>   |         '------'     '------'        |
>   |   192.168. |             | 192.168.103.71
>   |     102.71 |          .------.       |
>   |            |          | tap0 |       |
>   |            |          '------'       |
>   |            |             |           |
>   |            |          .------.       |
>   |            |          |  br  | 192.168.103.79
>   |            |          '------'       |
>   |           {VF}           |           |
>   |       .--------.      .------.       |
>   '=======|  eth2  |======| eth3 |======='
>           '--------'      '------'
> 192.168.102.79 |             |
>                | point-to-   |
>                |       point |
>                | connections |
> 192.168.102.80 |             |
>           .--------.      .------.
>   .=======|  eth2  |======| eth3 |=======.
>   |       '--------'      '------'       |
>   |           {VF}           |           |
>   |            |          .------.       |
>   |            |          |  br  | 192.168.103.80
>   |            |          '------'       |
>   |            |             |           |
>   |            |          .------.       |
>   |            |          | tap0 |       |
>   |   192.168. |          '------'       |
>   |     102.81 |             | 192.168.103.81
>   |         .------.     .------.        |
>   |      .--| eth1 |-----| eth0 |--.     |
>   |      |  '------'     '------'  |     |
>   |      |                         |     |
>   |      |  Virtual Machine - D    |     |
>   |      '-------------------------'     |
>   |                                      |
>   | Host - B                             |
>   '======================================'
> 
> 
> So, basically, 192.168.102 is the network where the VMs have a VF, and
> 192.168.103 is the network where the VMs use virtio for networking.
> 
> The netperf commands are all run on either Host-A or VM-C:
> 
>   netperf -H $ip -jcC -v 2 -t TCP_RR      -- -r 1024 -D L,R
>   netperf -H $ip -jcC -v 2 -t TCP_STREAM  -- -m 1024 -D L,R
> 
> 
>                    latency      throughput
>                     (usec)         Mbps
> cross-host:
>   A-B, eth2          185            932
>   A-B, eth3          185            935

This is actually PF-PF, right?  It would be interesting to load igbvf on
the hosts and determine VF-VF latency as well.

> same host, host-VM:
>   A-C, using VF      488           1085 (seen as high as 1280's)
>   A-C, virtio        150           4282

We know virtio has a shorter path for this test.

> cross-host, host-VM:
>   A-D, VF            489            938
>   A-D, virtio        288            889
> 
> cross-host, VM-VM:
>   C-D, VF            488            934
>   C-D, virtio        490            933
> 
> 
> While throughput for VFs is fine (near line-rate when crossing hosts),

FWIW, it's not too difficult to get line rate on a 1Gbps network, even
some of the emulated NICs can do it.  There will be a difference in host
CPU power to get it though, where it should theoretically be emulated >
virtio > pci-assign.

> the latency is horrible. Any options to improve that?

If you don't mind testing, I'd like to see VF-VF between the hosts (to
do this, don't assign eth2 an IP, just make sure it's up, then load the
igbvf driver on the host and assign an IP to one of the VFs associated
with the eth2 PF), and cross host testing using the PF for the guest
instead of the VF.  This should help narrow down how much of the latency
is due to using the VF vs the PF, since all of the virtio tests are
using the PF.  I've been suspicious that the VF adds some latency, but
haven't had a good test setup (or time) to dig very deep into it.
Thanks,

Alex


  reply	other threads:[~2011-04-25 18:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-21  1:57 performance of virtual functions compared to virtio David Ahern
2011-04-21  2:35 ` Alex Williamson
2011-04-21  8:07   ` Avi Kivity
2011-04-21 12:31     ` Stefan Hajnoczi
2011-04-21 13:09       ` Avi Kivity
2011-04-25 17:49         ` David Ahern
2011-04-26  8:19           ` Avi Kivity
2011-04-27 21:13             ` David Ahern
2011-04-28  8:07               ` Avi Kivity
2011-04-25 17:46     ` David Ahern
2011-04-26  8:20       ` Avi Kivity
2011-04-25 17:39   ` David Ahern
2011-04-25 18:13     ` Alex Williamson [this message]
2011-04-25 19:07       ` David Ahern
2011-04-25 19:29         ` Alex Williamson
2011-04-25 19:49           ` David Ahern
2011-04-25 20:27             ` Alex Williamson
2011-04-25 20:40               ` David Ahern
2011-04-25 21:02                 ` Alex Williamson
2011-04-25 21:14                   ` David Ahern
2011-04-25 21:18                     ` Alex Williamson
2011-04-25 20:49             ` Andrew Theurer
2011-05-02 18:58         ` David Ahern

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=1303755193.3431.50.camel@x201 \
    --to=alex.williamson@redhat.com \
    --cc=dsahern@gmail.com \
    --cc=kvm@vger.kernel.org \
    /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.