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! We still need 2 virtqueues for the slave-to-master message flow. > 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. Thanks! Stefan
signature.asc
Description: PGP signature
