On Tue, May 21, 2013 at 11:51:17AM +0300, Michael S. Tsirkin wrote:
> On Tue, May 21, 2013 at 01:04:55PM +0800, Amos Kong wrote:
> > > >
<snip>
> > > > + event_data = qobject_from_jsonf("{ 'name': %s }",
> > > > n->netclient_name);
> > > > + monitor_protocol_event(QEVENT_MAC_TABLE_CHANGED, event_data);
> > > > + qobject_decref(event_data);
> > > > +
> > > > return VIRTIO_NET_OK;
> > > > }
> > > >
> > >
> > > This makes it easy for guest to flood management with
> > > spurious events.
> >
> > > How about we set a flag after this, and avoid sending any more
> > > events until management queries the filter status?
> >
> > As you discussed in this thread, we need a flag to turn on/off
> > the event notification to avoid the flooding.
> >
> > But we could not set the flag in first mac-table change to turn off
> > the notification.
I'm wrong. Management's query for first event will enable
notification. If management don't query, no problem here,
because we only need to know the latest rx-filter state.
> > Becase one action(execute one cmd in guest) might
> > cause multiple events.
|| To clarify what I am proposing:
|| - on info mac-table -> clear flag
|| - on mac-table change -> test and set flag
|| if was not set -> send event to management
|| if was set -> do not send event
> I still think it will work.
Yes, it works, effectively avoid the event flooding.
> since the event does not have any
> information, what does it matter that we send one and not many events?
>
> > It would be flexible to add a parameter for query-mac-table to change
> > the flag. Or add a new command to change the flag.
> >
> > --
> > Amos.
>
> Looks a bit too complex, to me.
--
Amos.
