[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Re: [Qemu-devel] [RFC 1/2] spec/vhost-user: Introduce secondary channel for slave initiated requests
On 04/25/2017 07:55 PM, Maxime Coquelin wrote:
Hi Wei, On 04/24/2017 10:05 AM, Wei Wang wrote:On 04/14/2017 05:03 PM, Marc-André Lureau wrote:HiOn 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.htmlIndeed, 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.I sent second version of the RFC on April 14th, which comprises the implementation: https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg02467.html
Thanks, Maxime. I was trying to make the connection bidirectional (https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg02617.html), which was reported as problematic due to the possibility of race (though I think it can be solved by re-sending the msg in that rare case). Anyway, hope to see you guys' second channel based implementation to be merged soon. I would also consider to switch to use it then. Best, Wei
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]