Re: [Qemu-devel] [PATCH v2 1/2] net: introduce MAC_TABLE_CHANGED event

[Luiz Capitulino <lcapitulino@redhat.com>]

On Mon, 27 May 2013 09:10:11 -0400
Luiz Capitulino <lcapitulino@redhat.com> wrote:

> > We use the QMP event to notify management about the mac changing.
> > 
> > In this thread, we _wrongly_ considered to use qmp approach to delay
> > the event for avoiding the flooding.
> > 
> >   eg: monitor_protocol_event_throttle(NIC_RX_FILTER_CHANGED, 1000);
> > 
> > Now we have a solution (using a flag to turn on/off the notify) to avoid the
> > flooding, only emit the event if we have no un-read event.
> > 
> > If we want to (flag is on) emit the event, we wish the event be sent ASAP
> > (so event_throttle isn't needed).
> 
> Unfortunately this doesn't answer my question. I did understand why you're
> not using the event throttle API (which is because you don't want to slow down
> the guest, not the QMP client).
> 
> My point is whether coupling the event with the query command is really
> justified or even if it really fixes the problem. Two points:
> 
>  1. Coupling them is bad design, and will probably strike back, as we plan
>     for a better API for events where events can be disabled

I meant we may in the future, for example, introduce the ability to disable
commands (and events). One could argue that the event w/o a query command
is not that useful, as events can be lost. But loosing an event is one thing,
not having it because it got disabled by a side effect is another.

But anyway, my main point in this thread is to make sure we at least
justify having this coupling. Aren't we optimizing prematurely? Aren't
we optimizing for a corner case? That's what I want to see answered.