[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 5/9] monitor: suspend monitor instead of send CM

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 5/9] monitor: suspend monitor instead of send CMD_DROP
Date: Thu, 5 Jul 2018 11:47:30 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 07/04/2018 03:45 AM, Peter Xu wrote:
When we received too many qmp commands, previously we'll send
COMMAND_DROPPED events to monitors, then we'll drop the requests.  It
can only solve the flow control of the request queue, however it'll not
really work since we might queue unlimited events in the response queue
which is a potential risk.

Now instead of sending such an event, we stop consuming the client input
when we noticed that the queue is reaching its limitation before hand.
Then after we handled commands, we'll try to resume the monitor when

Is this the right thing to be doing?

If there is some event that we forgot to rate limit, and the client isn't consuming the output queue fast enough to keep up with events, we are making it so the client can't even send an OOB command that might otherwise stop the flood of events. Refusing to parse input when the client isn't parsing output makes sense when the output is a result of the input, but when the output is the result of events unrelated to the input, it might still be nice to be responsive (even if with COMMAND_DROPPED events) to OOB input. Then again, if events are not being parsed quickly by the client, it's debatable whether the client will parse COMMAND_DROPPED any sooner (even if COMMAND_DROPPED jumps the queue ahead of other events).

So I don't have a strong opinion on whether this patch is right or wrong, so much as voicing a potential concern to make sure I'm not overlooking something.

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

reply via email to

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