[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v6 18/27] monitor: send event when command queue f
From: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [RFC v6 18/27] monitor: send event when command queue full |
Date: |
Mon, 25 Dec 2017 14:18:25 +0800 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
On Mon, Dec 25, 2017 at 01:55:56PM +0800, Fam Zheng wrote:
> On Mon, 12/25 13:18, Peter Xu wrote:
> > On Thu, Dec 21, 2017 at 07:42:46PM +0800, Fam Zheng wrote:
> > > On Tue, 12/19 16:45, Peter Xu wrote:
> > > > Set maximum QMP command queue length to 8. If queue full, instead of
> > > > queue the command, we directly return a "command-dropped" event, telling
> > > > client that specific command is dropped.
> > > >
> > > > Note that this flow control mechanism is only valid if OOB is enabled.
> > > > If it's not, the effective queue length will always be 1, which strictly
> > > > follows original behavior of QMP command handling (which never drop
> > > > messages).
> > > >
> > > > Signed-off-by: Peter Xu <address@hidden>
> > > > ---
> > > > monitor.c | 17 ++++++++++++++++-
> > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/monitor.c b/monitor.c
> > > > index ed9a741d06..b571866659 100644
> > > > --- a/monitor.c
> > > > +++ b/monitor.c
> > > > @@ -4038,6 +4038,8 @@ static void monitor_qmp_bh_dispatcher(void *data)
> > > > }
> > > > }
> > > >
> > > > +#define QMP_REQ_QUEUE_LEN_MAX (8)
> > >
> > > Is this limit introspectable on QMP?
> >
> > Not yet. IMHO it's really QMP internal stuff, and I see no benefit so
> > far for a client to know about this...
>
> A client may need this number to batch (non-oob) commands without worrying
> about
> getting command-dropped event.
IMHO QMP batching will only be useful when performance matters, but
for now IMHO we don't need to worry much about QMP performance? When
we do, I suspect we need to do more things to make sure of it, and
exposing this single parameter may not really help much, say, for now
even the client batches the stuff, they still need to wait for the
completion of commands.
A rule of mine for this (which may not be exactly correct, but that's
what I'm following) is that we only export things that we are very
sure to export. For the rest, I would prefer to hide them, so that we
will make ourselves easier for compatibilities. Thanks,
--
Peter Xu
- Re: [Qemu-devel] [RFC v6 15/27] monitor: let suspend/resume work even with QMPs, (continued)
[Qemu-devel] [RFC v6 19/27] qapi: introduce new cmd option "allow-oob", Peter Xu, 2017/12/19
[Qemu-devel] [RFC v6 20/27] qmp: export qmp_dispatch_check_obj and allow "id", Peter Xu, 2017/12/19
[Qemu-devel] [RFC v6 21/27] qmp: support out-of-band (oob) execution, Peter Xu, 2017/12/19
[Qemu-devel] [RFC v6 22/27] qmp: isolate responses into io thread, Peter Xu, 2017/12/19