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

[Amos Kong <akong@redhat.com>]

On Tue, Jun 18, 2013 at 09:59:10AM +0800, Wenchao Xia wrote:
> 于 2013-6-14 15:45, Amos Kong 写道:
> > 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
> >   QMP client, but it could cause an unexpected delay (~1ms), guests
> >   guests normally expect rx-filter updates immediately.
> > 
> >   So we use a flag for each nic to avoid events flooding, the event
> >   is emitted once until the query command is executed. The flag
> >   implementation could not introduce unexpected delay.
> > 
> > There maybe exist an uncontrollable delay if we let Libvirt do the
> > real change, guests normally expect rx-filter updates immediately.
> > But it's another separate issue, we can investigate it when the
> > work in Libvirt side is done.


> > 
> Hi, Amos
>   This patch is for the user case that guest use a macvtap device right?
> could u add some document in commit message, so reader can understand
> what it trying to do?

I will add a single document later for it.
 docs/macprogramming-over-macvtap.txt

Thanks.
 
> Wenchao Xia

-- 
			Amos.