On Wed, Jun 05, 2013 at 06:42:13PM +0800, Amos Kong 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. > > For reducing length of output, we just return the entries of vlan > filter table that have active vlan. > > Event_throttle API can avoid the events to flood QMP client, but it > could cause an unexpected delay. So a flag for each nic is used to > avoid events flooding, if management doesn't query rx-filter after > it receives one event, new events won't be emitted to QMP monitor. > > 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.
What work is libvirt expected to do in response to these events ? It this just about updating the ebtables rules to allow packets with the newly configured MAC addr to be sent/received on the tap backend ? Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
