Re: [Qemu-devel] vhost-user graceful connect/disconnect

[Wei Wang <wei.w.wang@intel.com>]

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.

>
> It integrates into DPDK's librte_vhost so that existing vhost-user code
> works over AF_UNIX and virtio-vhost-user without code duplication or
> rewriting the devices.
>
> I hope you'll like the code when it's done.  If not, it still has useful
> code and ideas that would be needed to complete the vhost-pci RFC work
> like extending the PCI transport in the VIRTIO spec, handling vhost-user
> reconnection, etc.
>
> I'm aiming to send an RFC in the next 2 weeks.
>

Thanks. There would be at least three Slave handlers I can imagine:
- QEMU Slave handler to send master requests/responses to the guest
- Guest Slave handler
- QEMU Slave handler to send Guest Requests/responses to the master
I'm curious to see the code how could one be implemented so that the 
other other two could reuse.

I think the key issue is that we have a different viewpoint of protocol 
gating and protocol relaying. It is a high-level direction we need to 
align first before we could get into more details. Hope your upcoming 
code can get us a decision. Please also remember to reuse the dpdk code 
that my coworker posted to the dpdk mailinglist wherever possible, it 
may save your time to debug.

Best,
Wei