qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Wei Wang <wei.w.wang@intel.com>
To: Stefan Hajnoczi <stefanha@redhat.com>, virtio-dev@lists.oasis-open.org
Cc: qemu-devel@nongnu.org, "Michael S . Tsirkin" <mst@redhat.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>
Subject: Re: [Qemu-devel] [RFC virtio-dev] vhost-user-slave: add vhost-user slave device type
Date: Tue, 19 Dec 2017 16:00:13 +0800	[thread overview]
Message-ID: <5A38C70D.30207@intel.com> (raw)
In-Reply-To: <20171215170519.31392-1-stefanha@redhat.com>

On 12/16/2017 01:05 AM, Stefan Hajnoczi wrote:
> The vhost-user slave device facilitates vhost-user device emulation
> through vhost-user protocol exchanges and access to shared memory.
> Software-defined networking, storage, and other I/O appliances can
> provide services through this device.
>
> This device is based on Wei Wang's vhost-pci work.  The vhost-user slave
> device differs from vhost-pci because it is a single virtio device type
> that exposes the vhost-user protocol instead of a family of new virtio
> device types, one for each vhost-user device type.
>
> This device supports vhost-user slave and vhost-user master
> reconnection.  It also contains a UUID so that vhost-user slave programs
> can identify a specific device among many without using bus addresses.
>
> It is somewhat unconventional for a virtio device because it makes use
> of additional resources called doorbells, notifications, and shared
> memory.  A mapping of these resources to the virtio PCI transport is
> provided.  Other transports, such as CCW may not be able to support
> this device.

Hi Stefan,

Sorry for being late. I need to shift my focus to some other things for 
a week or two.

I still couldn't see how those problems can be solved with this slave 
device proposal (which vhost-pci doesn't have):

- The complexity of the "relaying" mechanism for two directions 
(GuestSlave<->QemuSlave<->Master). I couldn't think of a simple way to 
do this. If you know a *simple* way, could you please describe the 
detailed steps or show a picture of the details? (I think most of us 
couldn't see the true advantage over the vhost-pci's method)

- Reusability. We seem to have no chance to reuse one slave 
implementation for GuestSlave and QemuSlave, which also wasn't your 
intention as you mentioned. If this couldn't be solved, shall we give up 
this option?

Best,
Wei

  parent reply	other threads:[~2017-12-19  7:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-15 17:05 [Qemu-devel] [RFC virtio-dev] vhost-user-slave: add vhost-user slave device type Stefan Hajnoczi
2017-12-15 17:08 ` Stefan Hajnoczi
2017-12-19  8:00 ` Wei Wang [this message]
2017-12-19  9:02   ` [Qemu-devel] [virtio-dev] " Stefan Hajnoczi

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=5A38C70D.30207@intel.com \
    --to=wei.w.wang@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=virtio-dev@lists.oasis-open.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).