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

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, May 16, 2013 at 09:12:36AM -0600, Eric Blake wrote:
> On 05/16/2013 09:03 AM, Michael S. Tsirkin wrote:
> > On Thu, May 16, 2013 at 08:58:38AM -0600, Eric Blake wrote:
> >> On 05/16/2013 06:17 AM, Michael S. Tsirkin wrote:
> >>> On Thu, May 16, 2013 at 07:07:24PM +0800, Amos Kong wrote:
> >>>> Introduce this new QMP event to notify management after guest changes
> >>>> mac-table configuration.
> >>>>
> >>>
> >>> 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?
> >>>  
> >>
> >> Or use rate-limiting, similar to what we have done for other
> >> guest-triggered events (such as BALLOON_CHANGE), where management can
> >> then tweak the maximum frequency at which it is willing to receive events.
> >>
> >> -- 
> >> Eric Blake   eblake redhat com    +1-919-301-3266
> >> Libvirt virtualization library http://libvirt.org
> >>
> > 
> > I'm not sure how would management set the rate though,
> > and any throttling here might hurt the guest,
> > unlike the balloon.
> 
> If I understand how memballoon throttling works, throttling is NOT
> guest-visible; it merely controls how frequently the guest can trigger
> an event to the host.  The host always gets the latest guest status, but
> only after a timeout has occurred since the last event sent (therefore,
> 2 back-to-back changes mean that the second event isn't sent until the
> timeout elapses; 3 back-to-back means that the 2nd is dropped and only
> the first and third changes get sent, with the 3rd waiting until after
> the timeout).  That is, not all changes reach the host, the first change
> always happens immediately, but subsequent changes may be deferred until
> the timeout elapses, but the host will eventually see the final change,
> and no slower than the frequency it configures for the throttling.
> 
> Or are you are arguing that if the guest makes a request, but the host
> waits until a second has elapsed before it even gets the event to act on
> the request, then the guest has suffered a performance loss?

Yes, that's what I'm saying.

> > 
> > OTOH what I proposed kind of moderates itself automatically.
> 
> Your approach (no more events until the host has acknowleged) has a
> potential problem if the host misses the event (because of a libvirtd
> restart, for example - but then again, on a libvirtd restart, libvirt
> should probably query current state to get itself back in sync);

exactly
> and
> also means that the host sees stale event data if subsequent events were
> squelched because the host hasn't reacted to the first event yet.

So, let's not send any data in the event. Amos's patch does exafctly
that.

> The
> existing throttling approach ensures that if the event includes latest
> guest information, then the host doesn't even have to do do a query, and
> is guaranteed that reacting to the final event will always see the most
> recent request.  But most importantly, if the existing throttling works,
> why do we have to invent a one-off approach for this event instead of
> reusing existing code?

Because of the 1st issue above. A large delay because we
exceed an arbitrary throttling rate would be bad
for the guest. Contrast with delay in e.g.
device delete event.
The throttling mechanism is good for events that host cares
about, not for events that guest cares about.

> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>