From: "Alex Bennée" <alex.bennee@linaro.org>
To: Alyssa Ross <hi@alyssa.is>
Cc: "Michael S . Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH] docs: clarify absence of set_features in vhost-user
Date: Thu, 01 Sep 2022 13:12:06 +0100 [thread overview]
Message-ID: <877d2nnvce.fsf@linaro.org> (raw)
In-Reply-To: <20220901071803.273291-1-hi@alyssa.is>
Alyssa Ross <hi@alyssa.is> writes:
> The previous wording was (at least to me) ambiguous about whether a
> backend should enable features immediately after they were set using
> VHOST_USER_SET_PROTOCOL_FEATURES, or wait for support for protocol
> features to be acknowledged if it hasn't been yet before enabling
> those features.
>
> This patch attempts to make it clearer that
> VHOST_USER_SET_PROTOCOL_FEATURES should immediately enable features,
> even if support for protocol features has not yet been acknowledged,
> while still also making clear that the frontend SHOULD acknowledge
> support for protocol features.
>
> Previous discussion begins here:
> <https://lore.kernel.org/qemu-devel/87sgd1ktx9.fsf@alyssa.is/>
>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Alyssa Ross <hi@alyssa.is>
> ---
> docs/interop/vhost-user.rst | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
> index 3f18ab424e..c8b9771a16 100644
> --- a/docs/interop/vhost-user.rst
> +++ b/docs/interop/vhost-user.rst
> @@ -906,9 +906,9 @@ Front-end message types
> ``VHOST_USER_SET_FEATURES``.
>
> .. Note::
> - Back-ends that report ``VHOST_USER_F_PROTOCOL_FEATURES`` must
> - support this message even before ``VHOST_USER_SET_FEATURES`` was
> - called.
> + While QEMU should acknowledge ``VHOST_USER_F_PROTOCOL_FEATURES``, a
> + back-end must allow ``VHOST_USER_GET_PROTOCOL_FEATURES`` even if
> + ``VHOST_USER_F_PROTOCOL_FEATURES`` has not been acknowledged yet.
I think this is just restating the same logic from above introduced in:
fa9972662c (vhost-user.rst: add clarifying language about protocol negotiation)
that we don't need VHOST_USER_F_PROTOCOL_FEATURES to be acked by
VHOST_USER_SET_FEATURES? I agree the wording is hard to follow though. I
suspect what would really help is some clear message sequence diagrams
in the document showing the negotiation steps.
>
> ``VHOST_USER_SET_PROTOCOL_FEATURES``
> :id: 16
> @@ -923,8 +923,12 @@ Front-end message types
> ``VHOST_USER_SET_FEATURES``.
>
> .. Note::
> - Back-ends that report ``VHOST_USER_F_PROTOCOL_FEATURES`` must support
> - this message even before ``VHOST_USER_SET_FEATURES`` was called.
> + While QEMU should acknowledge ``VHOST_USER_F_PROTOCOL_FEATURES``, a
> + back-end must allow ``VHOST_USER_SET_PROTOCOL_FEATURES`` even if
> + ``VHOST_USER_F_PROTOCOL_FEATURES`` has not been acknowledged yet.
> + The back-end must not wait for ``VHOST_USER_SET_FEATURES`` before
> + enabling protocol features requested with
> + ``VHOST_USER_SET_PROTOCOL_FEATURES``.
>
> ``VHOST_USER_SET_OWNER``
> :id: 3
>
> base-commit: e93ded1bf6c94ab95015b33e188bc8b0b0c32670
--
Alex Bennée
next prev parent reply other threads:[~2022-09-01 12:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 7:18 [PATCH] docs: clarify absence of set_features in vhost-user Alyssa Ross
2022-09-01 12:12 ` Alex Bennée [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-08-13 9:48 Alyssa Ross
2020-08-13 16:28 ` no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877d2nnvce.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=hi@alyssa.is \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.