qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Denis Plotnikov <den-plotnikov@yandex-team.ru>
Cc: qemu-devel@nongnu.org, yc-core@yandex-team.ru, armbru@redhat.com,
	michael.roth@amd.com, vsementsov@yandex-team.ru
Subject: Re: [PATCH v1] qapi/qmp: Add timestamps to qmp command responses
Date: Fri, 7 Oct 2022 09:17:11 +0100	[thread overview]
Message-ID: <Yz/gh9JppXf408+2@redhat.com> (raw)
In-Reply-To: <20221007075208.175614-1-den-plotnikov@yandex-team.ru>

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	other threads:[~2022-10-07  8:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07  7:52 [PATCH v1] qapi/qmp: Add timestamps to qmp command responses Denis Plotnikov
2022-10-07  8:17 ` Daniel P. Berrangé [this message]

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=Yz/gh9JppXf408+2@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=den-plotnikov@yandex-team.ru \
    --cc=michael.roth@amd.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@yandex-team.ru \
    --cc=yc-core@yandex-team.ru \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).