Re: [Qemu-devel] [PATCH v6] net: add support of mac-programming over macvtap in QEMU side

[Amos Kong]

On Mon, Jun 17, 2013 at 09:11:27AM -0400, Luiz Capitulino wrote:
> On Fri, 14 Jun 2013 15:45:52 +0800
> Amos Kong <address@hidden> 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.