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

[Amos Kong]

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.