Re: [Qemu-devel] [PATCH v8 22/23] tests: qmp-test: verify command batching

[Eric Blake]

On 03/09/2018 03:00 AM, Peter Xu wrote:
> OOB introduced DROP event for flow control.  This should not affect old
> QMP clients.  Add a command batching check to make sure of it.
>
> Reviewed-by: Stefan Hajnoczi <address@hidden>
> Signed-off-by: Peter Xu <address@hidden>
> ---
>   tests/qmp-test.c | 22 ++++++++++++++++++++++
>   1 file changed, 22 insertions(+)

>   
> +    /*
> +     * Test command batching.  In current test OOB is not enabled, we
> +     * should be able to run as many commands in batch as we like.
> +     * Using 16 (>8, which is OOB queue length) to make sure OOB won't
> +     * break existing clients.  Note: this test does not control the
> +     * scheduling of QEMU's QMP command processing threads so it may
> +     * not really trigger batching inside QEMU.  This is just a
> +     * best-effort test.
> +     */
> +    for (i = 0; i < 16; i++) {
> +        qtest_async_qmp(qts, "{ 'execute': 'query-version' }");

Would the test be any more robust if we could generate a single string 
to send all at once, rather than multiple separate calls to 
qtest_async_qmp() (the overhead in generating separate strings means the 
monitor may have made progress before we send the next string).  But 
that can be a followup, if you want to pursue the idea.

> +    }
> +    /* Verify the replies to make sure no command is dropped. */
> +    for (i = 0; i < 16; i++) {
> +        resp = qtest_qmp_receive(qts);
> +        /* It should never be dropped.  Each of them should be a reply. */
> +        g_assert(qdict_haskey(resp, "return"));
> +        g_assert(!qdict_haskey(resp, "event"));
> +        QDECREF(resp);

Should we also be sending unique ids, and ensure that the responses 
arrive with ids in the same order?  Again, idea for a followup.

Reviewed-by: Eric Blake <address@hidden>

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org