Re: [virtio-comment] Re: [Qemu-devel] [RFC 1/2] spec/vhost-user: Introduce secondary channel for slave initiated requests

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

On 04/14/2017 05:03 PM, Marc-André Lureau wrote:
> Hi
>
> On Tue, Apr 11, 2017 at 5:53 PM Maxime Coquelin 
> <maxime.coquelin@redhat.com <mailto:maxime.coquelin@redhat.com>> wrote:
>
>     Hi Marc-André,
>
>     On 04/11/2017 03:06 PM, Marc-André Lureau wrote:
>     > Hi
>     >
>     > On Tue, Apr 11, 2017 at 12:10 PM Maxime Coquelin
>     > <maxime.coquelin@redhat.com <mailto:maxime.coquelin@redhat.com>
>     <mailto:maxime.coquelin@redhat.com
>     <mailto:maxime.coquelin@redhat.com>>> wrote:
>     >
>     >     This vhost-user specification update aims at enabling the
>     >     slave to send requests to the master using a dedicated socket
>     >     created by the master.
>     >
>     >     It can be used for example when the slave implements a device
>     >     IOTLB to send cache miss requests to the master.
>     >
>     >     The message types list is updated with an "Initiator" field to
>     >     indicate for each type whether the master and/or slave can
>     >     initiate the request.
>     >
>     >     Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com
>     <mailto:maxime.coquelin@redhat.com>
>     >     <mailto:maxime.coquelin@redhat.com
>     <mailto:maxime.coquelin@redhat.com>>>
>     >
>     >
>     > This is very similar to a patch I proposed for shutdown slave
>     initiated
>     > requests:
>     > https://lists.gnu.org/archive/html/qemu-devel/2016-04/msg00095.html
>
>     Indeed, thanks for pointing this out, I wasn't aware of your series.
>
>     I find your proposal of having dedicated messages types
>     (VHOST_USER_SLAVE_*) cleaner.
>
> ok
>
>     Are you ok if I handover your patch, and replace
>     VHOST_USER_SET_SLAVE_FD to VHOST_USER_SET_SLAVE_REQ_FD?
>
>
> They are very similar, I suggest you update your patch with the best 
> of both.
>
> I suppose you came to the same conclusion with me that trying to make 
> the communication both ways on the same fd would be quite difficult, 
> although it's a bit strange that the qemu implementation forces the 
> design of the protocol in some direction.
> --

When would you get the implementation patch ready? Thanks.

Best,
Wei