> Subject: Re: [evb] RE: [PATCH][RFC] net/bridge: add basic VEPA support > > On Monday 10 August 2009, Stephen Hemminger wrote: > > On Sun, 09 Aug 2009 14:19:08 +0300, Or Gerlitz > <ogerlitz@xxxxxxxxxxxx> wrote: > > > Looking in macvlan_set_multicast_list() it acts in a similar manner > to > > > macvlan_set_mac_address() in the sense that it calls dev_mc_sync(). > I > > > assume what's left is to add macvlan_hash_xxx multicast logic to > > > map/unmap multicast groups to what macvlan devices want to receive > them > > > and this way the flooding can be removed, correct? > > > > The device can just flood all multicast packets, since the filtering > > is done on the receive path anyway. Is this handled by one of the additional patches? In the current kernel tree macvlan code it looks as if multicast filtering is only handled by the physical device driver, but not on particular macvlan devices. > But we'd still have to copy the frames to user space (for both > macvtap and raw packet sockets) and exit from the guest to inject > it into its stack, right? I think it would be nice if you can implement what Or describes for macvlan and avoid flooding, and it doesn't sound too hard to do. I guess one advantage for macvlan (over the bridge) is that you can program in all information you have for the ports attached to it, e.g. MAC addresses and multicast addresses. So you could take advantage of that whereas the bridge always floods multicast frames to all ports. How would this work though, if the OS inside the guest wants to register to a particular multicast address? Is this propagated through the backend drivers to the macvlan/macvtap interface? Anna _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
