From: Wei Wang <wei.w.wang@intel.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
qemu-devel@nongnu.org, mukawa@igel.co.jp,
"Michael S. Tsirkin" <mst@redhat.com>,
"Maxime Coquelin" <maxime.coquelin@redhat.com>,
"n nikolaev" <n.nikolaev@virtualopensystems.com>
Subject: Re: [Qemu-devel] vhost-user graceful connect/disconnect
Date: Fri, 12 Jan 2018 14:53:43 +0800 [thread overview]
Message-ID: <5A585B77.4040404@intel.com> (raw)
In-Reply-To: <20180108160921.GC11758@stefanha-x1.localdomain>
On 01/09/2018 12:09 AM, Stefan Hajnoczi wrote:
> On Mon, Jan 08, 2018 at 07:22:37PM +0800, Wei Wang wrote:
>> On 01/05/2018 11:49 PM, Stefan Hajnoczi wrote:
>>> On Thu, Jan 04, 2018 at 07:15:38PM +0800, Wei Wang wrote:
>>>> On 01/04/2018 06:47 PM, Stefan Hajnoczi wrote:
>>>>> On Thu, Dec 21, 2017 at 06:01:29AM -0500, Marc-André Lureau wrote:
>>>>>
>>>>> I'm not going to prototype this yet, I'm working on virtio-vhost-user
>>>>> first, but eventually I might get back to -object vhost-user(-backend).
>>>>>
>>>> Hi Stefan, are you implementing the guest slave and vhost-pci driver (we've
>>>> posted to the dpdk mailinglist) as well? and do you have an estimation when
>>>> would the prototype be ready?
>>> I'm implementing the "[RFC virtio-dev] vhost-user-slave: add vhost-user
>>> slave device type" device in QEMU and DPDK in order to show how the
>>> ideas we've discussed work.
>>>
>>> Here is the VIRTIO spec link again:
>>> https://stefanha.github.io/virtio/vhost-user-slave.html#x1-2830007
>> There are four virtqueues documented in the spec, would two suffice? Request
>> and Response can be distinguished by VHOST_USER_REPLY_MASK.
> That's a good idea and I'll do it for the master-to-slave virtqueue.
>
> Unfortunately virtqueues are asymmetric so a single virtqueue cannot
> support the slave-to-master message flow (VHOST_USER_SET_SLAVE_REQ_FD):
> 1. Master puts an empty buffer onto vq.
> 2. Slave takes buffer and fills in a request. The buffer is now used.
> 3. Master pops the used buffer but there is no way to reply back to the
> slave!
Essentially, I think two virtqueues should be sufficient for
guest-to-host and host-to-guest communication.
Host-to-guest virtqueue: used for master request/response messages
passed to the guest slave (driver). The buffer can be primed by the
guest driver (like virtio-net rxq).
Guest-to-host virtqueue: used for guest slave request/response messages,
like virtio-net txq, it doesn't need to prime buffers in advance.
Best,
Wei
next prev parent reply other threads:[~2018-01-12 6:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-19 16:21 [Qemu-devel] vhost-user graceful connect/disconnect Stefan Hajnoczi
2017-12-20 6:45 ` Fam Zheng
2017-12-20 15:56 ` Stefan Hajnoczi
2017-12-21 11:01 ` Marc-André Lureau
2018-01-04 10:47 ` Stefan Hajnoczi
2018-01-04 11:15 ` Wei Wang
2018-01-05 15:49 ` Stefan Hajnoczi
2018-01-08 11:22 ` Wei Wang
2018-01-08 16:09 ` Stefan Hajnoczi
2018-01-12 6:53 ` Wei Wang [this message]
2018-01-12 10:45 ` Stefan Hajnoczi
2018-01-04 16:53 ` Michael S. Tsirkin
2018-01-05 16:14 ` 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=5A585B77.4040404@intel.com \
--to=wei.w.wang@intel.com \
--cc=marcandre.lureau@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=mukawa@igel.co.jp \
--cc=n.nikolaev@virtualopensystems.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 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).