qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "Maurício Almeida" <malmeida@inf.ufsm.br>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] Doubts about Kvm architecture
Date: Wed, 31 May 2017 16:44:43 -0500	[thread overview]
Message-ID: <5c096fa0-ba9b-86aa-6f08-e5b9d30a2743@redhat.com> (raw)
In-Reply-To: <CAEB0U7P0Sk0cNQbPynrzJ5MMdQ5=zdMFnf5neWc6PjfQ1Z=Z2Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

On 05/31/2017 11:56 AM, Maurício Almeida wrote:

> The Traffic of Virtio was 956 MB/s while e1000 Emulated Driver was 192
> MB/s, both using Packet size of 1518 Bytes.

The quick answer - yes, that's the expected results, because paravirt is
SOOO much more direct than fully-emulated.  Everything done in the e1000
driver has to emulate what hardware would do, which tends to be a LOT of
register reads and writes to device memory, which in turn implies a LOT
of VMEXITs with corresponding overhead as you are paging between the
guest and host to handle the full sequence.  Meanwhile, the virtio
driver was designed from the ground up to be as efficient as possible,
by intentionally arranging memory layout and handshake protocols so that
there are as few memory-mapped register writes, and therefore as few
VMEXITs, as possible, for better speed and multithreading.

> 
> Why when it used e1000 Emulated Driver the traffic was to low and use only
> one Cpu all the time?

For any modern OS, the e1000 driver should only be used as a crutch to
get the system up and running until you can install and switch over to
the virtio drivers (we have it because it is a driver that is most
likely already installed on a guest OS out-of-the-box, while the virtio
driver might be an extra download or install after the initial guest
install has completed).  So optimizing the e1000 driver to run on
multiple vcpus is not our priority; rather, you should be optimizing
your guest provisioning setup to get switched over to the virtio drivers
as soon as possible.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2017-05-31 21:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-31 16:56 [Qemu-devel] Doubts about Kvm architecture Maurício Almeida
2017-05-31 21:44 ` Eric Blake [this message]
     [not found] <CAEB0U7On7OPAytSMjx94pfMKswuEzrty87Asz_9TYV_wrc4p4w@mail.gmail.com>
2017-05-31 17:48 ` Mihai Donțu

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=5c096fa0-ba9b-86aa-6f08-e5b9d30a2743@redhat.com \
    --to=eblake@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=malmeida@inf.ufsm.br \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).