qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v8 16/23] monitor: send event when command queue


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v8 16/23] monitor: send event when command queue full
Date: Sat, 10 Mar 2018 20:11:10 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 03/09/2018 02:59 AM, Peter Xu wrote:
Set maximum QMP command queue length to 8.  If queue full, instead of

If the queue is full

queue the command, we directly return a "command-dropped" event, telling

s/queue/queuing/

client that specific command is dropped.

s/client that/the client that a/


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

s/drop/drops/

messages).

Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
---
  monitor.c | 18 +++++++++++++++++-
  1 file changed, 17 insertions(+), 1 deletion(-)


diff --git a/monitor.c b/monitor.c
index 5104e5db07..4d57a8d341 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4007,6 +4007,8 @@ static void monitor_qmp_bh_dispatcher(void *data)
      }
  }
+#define QMP_REQ_QUEUE_LEN_MAX (8)

Parens are redundant on a single int, but it doesn't hurt to leave them in a macro definition.

@@ -4049,6 +4054,18 @@ static void handle_qmp_command(JSONMessageParser 
*parser, GQueue *tokens)
      if (!qmp_oob_enabled(mon)) {
          monitor_suspend(mon);
          req_obj->need_resume = true;
+    } else {
+        /* Drop the request if queue is full. */
+        if (mon->qmp.qmp_requests->length >= QMP_REQ_QUEUE_LEN_MAX) {
+            qemu_mutex_unlock(&mon->qmp.qmp_queue_lock);
+            qapi_event_send_command_dropped(id,
+                                            COMMAND_DROP_REASON_QUEUE_FULL,
+                                            NULL);

Most qapi_event_send_* callers pass &error_abort (migration/ram.c being the only exception I could find); why not this one? I'm changing it for consistency; we can revert back to NULL if testing finds a problem with it.

Reviewed-by: Eric Blake <address@hidden>

--
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]