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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]

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?

> 
> 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); 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.  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?

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]