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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Thu, 16 May 2013 18:17:23 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> > 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?

Sorry to restart this week old discussion, but I'm now reviewing the patch
in question and I dislike how we're coupling the event and the query
command.

> Because of the 1st issue above. A large delay because we

Has this been measured? How long is this large delay?

Also, is it impossible for management to issue query-rx-filter
on a reasonable rate that would also cause the same problems?
IOW, how can we be sure we're fixing anything without trying it
on a real use-case scenario?

> 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
> > 
> 
> 
>