virtio-comment

 View Only
Back to discussions
Expand all | Collapse all

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

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

    Posted 04-26-2017 11:29
    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
    >>> <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.
    >
    > 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







Related Content