qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v2 1/2] net: introduce MAC_TABLE_CHANGED event
Date: Thu, 16 May 2013 18:06:48 +0300

On Thu, May 16, 2013 at 06:03:26PM +0300, 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.
> 
> OTOH what I proposed kind of moderates itself automatically.

To clarify the issue:
- guest might be changing macs a lot not because it
        is malicious, but because it has a reason to do it.
        delaying the filter update for such a guest
        would drop lots of packets.

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

This way management does not get events faster than
it can handle them.

> -- 
> MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]