From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d3L6b-0001tM-1B for qemu-devel@nongnu.org; Wed, 26 Apr 2017 07:27:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d3L6X-0000q1-Tp for qemu-devel@nongnu.org; Wed, 26 Apr 2017 07:27:33 -0400 Received: from mga14.intel.com ([192.55.52.115]:13976) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d3L6X-0000ou-M4 for qemu-devel@nongnu.org; Wed, 26 Apr 2017 07:27:29 -0400 Message-ID: <5900848C.60007@intel.com> Date: Wed, 26 Apr 2017 19:29:16 +0800 From: Wei Wang MIME-Version: 1.0 References: <20170411101002.28451-1-maxime.coquelin@redhat.com> <20170411101002.28451-2-maxime.coquelin@redhat.com> <7dfc220c-b22b-bd7d-53af-caf49275b66c@redhat.com> <58FDB1BD.4090601@intel.com> <62b87247-b778-081f-c9c8-cb7bbc195987@redhat.com> In-Reply-To: <62b87247-b778-081f-c9c8-cb7bbc195987@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [virtio-comment] Re: [RFC 1/2] spec/vhost-user: Introduce secondary channel for slave initiated requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Maxime Coquelin , =?UTF-8?B?TWFyYy1BbmRyw6k=?= =?UTF-8?B?IEx1cmVhdQ==?= , mst@redhat.com, vkaplans@redhat.com, jasowang@redhat.com, wexu@redhat.com, peterx@redhat.com, yuanhan.liu@linux.intel.com, virtio-comment@lists.oasis-open.org, qemu-devel@nongnu.org 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: >>> Hi >>> >>> On Tue, Apr 11, 2017 at 5:53 PM Maxime Coquelin >>> > 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 >>> > >>> >> >> 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 >> >>> > >> >> >>> > >>> > >>> > 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. > > 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