[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support
From: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support |
Date: |
Fri, 15 Sep 2017 11:50:57 +0800 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Thu, Sep 14, 2017 at 04:19:11PM +0100, Stefan Hajnoczi wrote:
> On Thu, Sep 14, 2017 at 01:15:09PM +0200, Marc-André Lureau wrote:
> > There should be a limit in the number of requests the thread can
> > queue. Before the patch, the limit was enforced by system socket
> > buffering I think. Now, should oob commands still be processed even if
> > the queue is full? If so, the thread can't be suspended.
>
> I agree.
>
> Memory usage must be bounded. The number of requests is less important
> than the amount of memory consumed by them.
>
> Existing QMP clients that send multiple QMP commands without waiting for
> replies need to rethink their strategy because OOB commands cannot be
> processed if queued non-OOB commands consume too much memory.
Thanks for pointing out this. Yes the memory usage problem is valid,
as Markus pointed out as well in previous discussions (in "Flow
Control" section of that long reply). Hopefully this series basically
can work from design prospective, then I'll add this flow control in
next version.
Regarding to what we should do if the limit is reached: Markus
provided a few options, but the one I prefer most is that we don't
respond, but send an event showing that a command is dropped.
However, I would like it not queued, but a direct reply (after all,
it's an event, and we should not need to care much on ordering of it).
Then we can get rid of the babysitting of those "to be failed"
requests asap, meanwhile we don't lose anything IMHO.
I think I also missed at least a unit test for this new interface.
Again, I'll add it after the whole idea is proved solid. Thanks,
--
Peter Xu
- [Qemu-devel] [RFC 10/15] monitor: introduce monitor_qmp_respond(), (continued)
- [Qemu-devel] [RFC 10/15] monitor: introduce monitor_qmp_respond(), Peter Xu, 2017/09/14
- [Qemu-devel] [RFC 11/15] monitor: separate QMP parser and dispatcher, Peter Xu, 2017/09/14
- [Qemu-devel] [RFC 12/15] monitor: enable IO thread for (qmp & !mux) typed, Peter Xu, 2017/09/14
- [Qemu-devel] [RFC 13/15] qapi: introduce new cmd option "allow-oob", Peter Xu, 2017/09/14
- [Qemu-devel] [RFC 14/15] qmp: support out-of-band (oob) execution, Peter Xu, 2017/09/14
- [Qemu-devel] [RFC 15/15] qmp: let migrate-incoming allow out-of-band, Peter Xu, 2017/09/14
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Marc-André Lureau, 2017/09/14
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Stefan Hajnoczi, 2017/09/14
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support,
Peter Xu <=
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Stefan Hajnoczi, 2017/09/15
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Daniel P. Berrange, 2017/09/15
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Dr. David Alan Gilbert, 2017/09/15
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Daniel P. Berrange, 2017/09/15
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Dr. David Alan Gilbert, 2017/09/15
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Daniel P. Berrange, 2017/09/15
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Dr. David Alan Gilbert, 2017/09/15
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Daniel P. Berrange, 2017/09/15
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Stefan Hajnoczi, 2017/09/15
- Re: [Qemu-devel] [RFC 00/15] QMP: out-of-band (OOB) execution support, Dr. David Alan Gilbert, 2017/09/15