All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	wei.w.wang@intel.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] vhost-pci and virtio-vhost-user
Date: Tue, 23 Jan 2018 11:52:40 +0000	[thread overview]
Message-ID: <20180123115240.GD6565@stefanha-x1.localdomain> (raw)
In-Reply-To: <9c05c203-7d1f-dbea-5577-4d85c42e82ee@redhat.com>

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

On Mon, Jan 22, 2018 at 11:54:41AM +0800, Jason Wang wrote:
> On 2018年01月20日 01:20, Stefan Hajnoczi wrote:
> > > I don't propose any new idea. I just want to know what's the advantage of
> > > vhost-pci over zerocopy. Both needs one time of copy, the difference is the
> > > vhost-pci did it inside a guest but zerocopy did in on host.
> > Exitless VM2VM communication is desirable if you cannot run software on
> > the host or if both endpoints are already in VMs.  In that case running
> > one thing in a VM and another on the host doesn't make sense.
> 
> Well, I must have missed anything, I don't see why we can not run virtio-net
> backend on host. Especially it only does L2 stuffs, higher level of service
> could be provided by another VM for sure. So it looks to me
> virtio-vhost-user is just a split device implementation which is irreverent
> to the service it could provide.
> 
> Maybe you can provide a concrete examples of virtio-vhost-user and its
> advantages?
[...]
> > 
> > The obvious environment where this applies is in the cloud where
> > everything is a VM.
> 
> So a typical setup makes the VMs can already talk to each other through
> ethernet(virtio-net). Virtio-vhost-user looks much less flexible than exist
> stuffs. The only possible advantage of virtio-vhost-user is its performance
> or security which still need to be proved.

I look forward to performance results but in the meantime consider
existing vhost-user use cases.  Those applications could just use
network communication too (e.g. iSCSI instead of vhost-user-scsi).  They
choose vhost-user mainly because it's faster (zerocopy, no vmexits, and
no network protocol overhead).

There are other advantages too.  In the iSCSI case, guests need
configuration details to establish the iSCSI connection.  In the
virtio-scsi case the guests only need the virtio-scsi driver and no
configuration to access the LUNs.  It's simpler on the guest side!

So the reasons for virtio-vhost-user are the same as vhost-user PLUS
some users choose to deploy everything in VMs and cannot run host
userspace process.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2018-01-23 11:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10 16:14 [Qemu-devel] vhost-pci and virtio-vhost-user Stefan Hajnoczi
2018-01-11  6:31 ` Wei Wang
2018-01-11  9:56   ` Stefan Hajnoczi
2018-01-12  6:44     ` Wei Wang
2018-01-12 10:37       ` Stefan Hajnoczi
2018-01-14  3:36         ` Wang, Wei W
2018-01-15 14:02           ` Stefan Hajnoczi
2018-01-11 10:57 ` Jason Wang
2018-01-11 15:23   ` Stefan Hajnoczi
2018-01-12  3:32     ` Jason Wang
2018-01-12  5:20       ` Yang, Zhiyong
2018-01-15  3:09         ` Jason Wang
2018-01-12 10:18       ` Stefan Hajnoczi
2018-01-15  6:56         ` Jason Wang
2018-01-15  7:59           ` Wei Wang
2018-01-15  8:34             ` Jason Wang
2018-01-15 10:43               ` Wei Wang
2018-01-16  5:33                 ` Jason Wang
2018-01-17  8:44                   ` Wei Wang
2018-01-15 13:56           ` Stefan Hajnoczi
2018-01-16  5:41             ` Jason Wang
2018-01-18 10:51               ` Stefan Hajnoczi
2018-01-18 11:51                 ` Jason Wang
2018-01-19 17:20                   ` Stefan Hajnoczi
2018-01-22  3:54                     ` Jason Wang
2018-01-23 11:52                       ` Stefan Hajnoczi [this message]
2018-01-15  7:56         ` Wei Wang

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=20180123115240.GD6565@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=wei.w.wang@intel.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.