qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1] qapi/qmp: Add timestamps to qmp command responses


From: Daniel P . Berrangé
Subject: Re: [PATCH v1] qapi/qmp: Add timestamps to qmp command responses
Date: Fri, 7 Oct 2022 09:17:11 +0100
User-agent: Mutt/2.2.7 (2022-08-07)

On Fri, Oct 07, 2022 at 10:52:08AM +0300, Denis Plotnikov wrote:
> Add "start" & "end" time values to qmp command responses.
> 
> These time values are added to let the qemu management layer get the exact
> command execution time without any other time variance which might be brought 
> by
> other parts of management layer or qemu internals. This is particulary useful
> for the management layer logging for later problems resolving.
> 
> Example of result:
> 
>     ./qemu/scripts/qmp/qmp-shell /tmp/qmp.socket
> 
>     (QEMU) query-status
>     {"end": {"seconds": 1650367305, "microseconds": 831032},
>      "start": {"seconds": 1650367305, "microseconds": 831012},
>      "return": {"status": "running", "singlestep": false, "running": true}}
> 
> The responce of the qmp command contains the start & end time of
> the qmp command processing.
> 
> Suggested-by: Andrey Ryabinin <arbn@yandex-team.ru>
> Signed-off-by: Denis Plotnikov <den-plotnikov@yandex-team.ru>
> ---
> v0->v1:
>  - remove interface to control "start" and "end" time values: return 
> timestamps unconditionally
>  - add description to qmp specification
>  - leave the same timestamp format in "seconds", "microseconds" to be 
> consistent with events
>    timestamp
>  - fix patch description
> 
>  docs/interop/qmp-spec.txt | 20 ++++++++++++++++++--
>  qapi/qmp-dispatch.c       | 18 ++++++++++++++++++
>  2 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/interop/qmp-spec.txt b/docs/interop/qmp-spec.txt
> index b0e8351d5b261..d1cca8bc447ce 100644
> --- a/docs/interop/qmp-spec.txt
> +++ b/docs/interop/qmp-spec.txt
> @@ -158,7 +158,9 @@ responses that have an unknown "id" field.
>  
>  The format of a success response is:
>  
> -{ "return": json-value, "id": json-value }
> +{ "return": json-value, "id": json-value,
> +  "start": {"seconds": json-value, "microseconds": json-value},
> +  "end": {"seconds": json-value, "microseconds": json-value} }
>  
>   Where,
>  
> @@ -169,13 +171,21 @@ The format of a success response is:
>    command does not return data
>  - The "id" member contains the transaction identification associated
>    with the command execution if issued by the Client
> +- The "start" member contains the exact time of when the command has been
> +  stated to be processed. It is a fixed json-object with time in
> +  seconds and microseconds relative to the Unix Epoch (1 Jan 1970)

If I may make a suggestion

- The "start" member contains the exact time of when the server
  started executing the command. This excludes any time the
  command request spent queued, after reading it off the wire.

  It is a fixed json-object with time in seconds and microseconds
  relative to the Unix Epoch (1 Jan 1970)

> +- The "end" member contains the exact time of when the command has been
> +  finished to be processed. It is a fixed json-object with time in
> +  seconds and microseconds relative to the Unix Epoch (1 Jan 1970)

- The "end" member contains the exact time of when the server
  finished executing the command. This excludes any time the
  command response spent queued, waiting to be sent on the wire.

  It is a fixed json-object with time in seconds and microseconds
  relative to the Unix Epoch (1 Jan 1970)

> @@ -184,6 +194,12 @@ The format of an error response is:
>    not attempt to parse this message.
>  - The "id" member contains the transaction identification associated with
>    the command execution if issued by the Client
> +- The "start" member contains the exact time of when the command has been
> +  stated to be processed. It is a fixed json-object with time in
> +  seconds and microseconds relative to the Unix Epoch (1 Jan 1970)
> +- The "end" member contains the exact time of when the command has been
> +  finished to be processed. It is a fixed json-object with time in
> +  seconds and microseconds relative to the Unix Epoch (1 Jan 1970)

Same suggestion as above of course.


Could you also add something to tests/qtest/qmp-test.c to validate
that the start/end fields are present for command responses and
errors, and also validate that end > start as a sanity check.


IIUC, this change will transparently apply to the QEMU guest agent
too since your change looks to be in the shared code for QMP ?

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]