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

[Amos Kong]

On Tue, Jun 04, 2013 at 02:43:11PM +0800, Amos Kong wrote:
> 


> I did more tests in clear environment, and found that the guest hang/slow
> (no response from monitor) is caused by flooding events. I could not
> reproduce it with upstream qemu [1]
> 
> If I set event_throttle to 1 ~ 1000, the problem doesn't occur.
> 
> It's easier to reproduce this problem by changing vlan config,
> not because it passes more data with VQ cmd, but it will cause more
> events.
> 
> 
> In this case, we can set event_throttle to 1 for _RX_FILTER_CHANGED
> event to avoid it slows guest. The 1 ms delay should be acceptabled?

Just discussed with mst in IRC.

Here we have two problem:
(1) huge number of events will flood monitor client (management),
(2) emitting huge number of events will slow guest itself.

Both the flag (nc->rxfilter_notify_enabled) and event_throttle API
can be used to avoid problem (1).

Event_throttle API can clearly avoid problem (2).

In real testing, I found it's difficult to reproduce problem (2) if we
already use the flag. It seems response time is larger enough, some
events will be dropped, guest could not be slowed.

Michael told me that we have many ways to slow guest itself, so it's
not a big issue here.

We care about the delay of responsing event, so we should only use
control flag (As my patch v4).

What's your opinion?