| Message ID | 1443189647-11417-6-git-send-email-armbru@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 09/25/2015 08:00 AM, Markus Armbruster wrote: > VSERPORT_CHANGE is emitted when the guest opens or closes a > virtio-serial port. The event's member "id" identifies the port. > > When several events arrive quickly, throttling drops all but the last > of them. Because of that, a QMP client must assume that *any* port > may have changed state when it receives a VSERPORT_CHANGE event and > throttling may have happened. > > Make the event more useful by throttling it for each port separately. > > Signed-off-by: Markus Armbruster <armbru@redhat.com> > --- > monitor.c | 18 ++++++++++++++++-- > 1 file changed, 16 insertions(+), 2 deletions(-) > All future differentiation would be added as additional special cases within the hash functions, but I like this approach for keeping the rest of the algorithm independent from what the hashing considers as equivalent. Reviewed-by: Eric Blake <eblake@redhat.com>
Eric Blake <eblake@redhat.com> writes: > On 09/25/2015 08:00 AM, Markus Armbruster wrote: >> VSERPORT_CHANGE is emitted when the guest opens or closes a >> virtio-serial port. The event's member "id" identifies the port. >> >> When several events arrive quickly, throttling drops all but the last >> of them. Because of that, a QMP client must assume that *any* port >> may have changed state when it receives a VSERPORT_CHANGE event and >> throttling may have happened. >> >> Make the event more useful by throttling it for each port separately. >> >> Signed-off-by: Markus Armbruster <armbru@redhat.com> >> --- >> monitor.c | 18 ++++++++++++++++-- >> 1 file changed, 16 insertions(+), 2 deletions(-) >> > > All future differentiation would be added as additional special cases > within the hash functions, but I like this approach for keeping the rest > of the algorithm independent from what the hashing considers as equivalent. Should that ever become unwieldy, we can easily add indirections right there. > Reviewed-by: Eric Blake <eblake@redhat.com> Thanks!
diff --git a/monitor.c b/monitor.c index 9807a5b..7e21407 100644 --- a/monitor.c +++ b/monitor.c @@ -567,8 +567,13 @@ static void monitor_qapi_event_handler(void *opaque) static unsigned int qapi_event_throttle_hash(const void *key) { const MonitorQAPIEventState *evstate = key; + unsigned int hash = evstate->event * 255; - return evstate->event * 255; + if (evstate->event == QAPI_EVENT_VSERPORT_CHANGE) { + hash += g_str_hash(qdict_get_str(evstate->qdict, "id")); + } + + return hash; } static gboolean qapi_event_throttle_equal(const void *a, const void *b) @@ -576,7 +581,16 @@ static gboolean qapi_event_throttle_equal(const void *a, const void *b) const MonitorQAPIEventState *eva = a; const MonitorQAPIEventState *evb = b; - return eva->event == evb->event; + if (eva->event != evb->event) { + return FALSE; + } + + if (eva->event == QAPI_EVENT_VSERPORT_CHANGE) { + return !strcmp(qdict_get_str(eva->qdict, "id"), + qdict_get_str(evb->qdict, "id")); + } + + return TRUE; } static void monitor_qapi_event_init(void)
VSERPORT_CHANGE is emitted when the guest opens or closes a virtio-serial port. The event's member "id" identifies the port. When several events arrive quickly, throttling drops all but the last of them. Because of that, a QMP client must assume that *any* port may have changed state when it receives a VSERPORT_CHANGE event and throttling may have happened. Make the event more useful by throttling it for each port separately. Signed-off-by: Markus Armbruster <armbru@redhat.com> --- monitor.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)