Peter Xu <pet...@redhat.com> writes:
> Now it was not used any more, drop it. We can still do that since
> out-of-band is still experimental, and this event is only used when
> out-of-band is enabled.
>
> Signed-off-by: Peter Xu <pet...@redhat.com>
> ---
> docs/interop/qmp-spec.txt | 5 +++--
> qapi/misc.json | 40 ---------------------------------------
> 2 files changed, 3 insertions(+), 42 deletions(-)
>
> diff --git a/docs/interop/qmp-spec.txt b/docs/interop/qmp-spec.txt
> index 8f7da0245d..67e44a8120 100644
> --- a/docs/interop/qmp-spec.txt
> +++ b/docs/interop/qmp-spec.txt
> @@ -130,8 +130,9 @@ to pass "id" with out-of-band commands. Passing it with
> all commands
> is recommended for clients that accept capability "oob".
>
> If the client sends in-band commands faster than the server can
> -execute them, the server will eventually drop commands to limit the
> -queue length. The sever sends event COMMAND_DROPPED then.
> +execute them, the server will stop reading the requests from the QMP
> +channel until the request queue length is reduced to an acceptable
> +range.
The change described by this documentation update is in the previous
commit. This commit merely cleans up unused code. Instead of moving
the doc update to the previous commit, we can simply squash the two
commits.
Let's add a hint on managing flow of in-band commands to keep the
monitor available for out-of-band commands. Here's my try:
If the client sends in-band commands faster than the server can
execute them, the server will stop reading the requests from the QMP
channel until its request queue length falls below the limit. To
keep the monitor available for out-of-band commands, the client has
to manage the flow of in-band commands.
Of course, anyone trying to put this hint to use will need to know the
actual request queue limit. Options:
* Make it ABI by documenting it here
* Let the client configure it with a suitable command
* Let the introspect it with a suitable command
>
> Only a few commands support out-of-band execution. The ones that do
> have "allow-oob": true in output of query-qmp-schema.
> diff --git a/qapi/misc.json b/qapi/misc.json
> index d450cfef21..2c1a6119bf 100644
> --- a/qapi/misc.json
> +++ b/qapi/misc.json
> @@ -3432,46 +3432,6 @@
> ##
> { 'command': 'query-sev-capabilities', 'returns': 'SevCapability' }
>
> -##
> -# @CommandDropReason:
> -#
> -# Reasons that caused one command to be dropped.
> -#
> -# @queue-full: the command queue is full. This can only occur when
> -# the client sends a new non-oob command before the
> -# response to the previous non-oob command has been
> -# received.
> -#
> -# Since: 2.12
> -##
> -{ 'enum': 'CommandDropReason',
> - 'data': [ 'queue-full' ] }
> -
> -##
> -# @COMMAND_DROPPED:
> -#
> -# Emitted when a command is dropped due to some reason. Commands can
> -# only be dropped when the oob capability is enabled.
> -#
> -# @id: The dropped command's "id" field.
> -# FIXME Broken by design. Events are broadcast to all monitors. If
> -# another monitor's client has a command with the same ID in flight,
> -# the event will incorrectly claim that command was dropped.
> -#
> -# @reason: The reason why the command is dropped.
> -#
> -# Since: 2.12
> -#
> -# Example:
> -#
> -# { "event": "COMMAND_DROPPED",
> -# "data": {"result": {"id": "libvirt-102",
> -# "reason": "queue-full" } } }
> -#
> -##
> -{ 'event': 'COMMAND_DROPPED' ,
> - 'data': { 'id': 'any', 'reason': 'CommandDropReason' } }
> -
> ##
> # @set-numa-node:
> #
