[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Wei Wang
Subject: Re: [Qemu-devel] vhost-user graceful connect/disconnect
Date: Mon, 08 Jan 2018 19:22:37 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]