On Mon, Jun 17, 2013 at 09:11:27AM -0400, Luiz Capitulino wrote: > On Fri, 14 Jun 2013 15:45:52 +0800 > Amos Kong <ak...@redhat.com> wrote: > > > Currently macvtap based macvlan device is working in promiscuous > > mode, we want to implement mac-programming over macvtap through > > Libvirt for better performance. > > > > Design: > > QEMU notifies Libvirt when rx-filter config is changed in guest, > > then Libvirt query the rx-filter information by a monitor command, > > and sync the change to macvtap device. Related rx-filter config > > of the nic contains main mac, rx-mode items and vlan table. > > > > This patch adds a QMP event to notify management of rx-filter change, > > and adds a monitor command for management to query rx-filter > > information. > > > > Test: > > If we repeatedly add/remove vlan, and change macaddr of vlan > > interfaces in guest by a loop script. > > > > Result: > > The events will flood the QMP client(management), management takes > > too much resource to process the events. > > > > Event_throttle API (set rate to 1 ms) can avoid the events to flood > > I doubt this is a valid value. Today, the three events that use the event > throttle API set the delay rate to 1000 ms.
We even could not bear the 1ms delay, 1000 is too large. > > QMP client, but it could cause an unexpected delay (~1ms), guests > > guests normally expect rx-filter updates immediately. > > What you mean by "immediately"? There's a round-trip to the host plus > all the stuff QEMU will execute to fulfil the request. And how did you > measure this, btw? 'Immediately' means ASAP here. We could not prevent qemu to execute. But we replace throttle API by a smart flag. Throttle API might be a good design, but it's redundant in this case. > What you have to do is is to measure your test-case in three different > scenarios: > > 1. Against upstream QEMU (ie. no patches) > 2. With the event throttle API > 3. With this patch 1. use flag: the time used to check the flag, we can ignore the delay. 2. use throttle API: delay is 1ms or 1000ms. ~0ms VS. more than 1000ms > Only then you'll be able which is better. Amos.
