On Tue, 29 Apr 2014 17:20:21 -0400 Vlad Yasevich <vyasevic@xxxxxxxxxx> wrote: > This patch series is a re-implementation of prior attempts to support > non-promiscuous bridge ports. > > The basic concept is the same as before. The bridge keeps > track of the ports that support learning and flooding packets > to unknown destinations. We call these ports auto-discovery > ports since they automatically discover who is behind them through > learning and flooding. > > If flooding and learning are disabled via flags, then the port > requires static configuration to tell it which mac addresses > are behind it. This is accomplished through adding of fdbs. > These fdbs should be static as dynamic fdbs can expire and systems > will become unreachable due to lack of flooding. > > If the user marks all ports are needing static configuration then > we can safely make them non-promiscuous, we will know all the > information about them. > > If the user leaves only 1 port as automatic, then we can mark > that port as not-promiscuous as well. One could think of > this a edge relay similar to what's support by embedded switches > in SRIOV devices. Since we have all the information about the > other ports, we can just program the mac addresses into the > single automatic port to receive all necessary traffic. > > In other cases, we keep all ports promiscuous as before. > > There are some other cases when promiscuous mode has to be turned > back on. One is when the bridge itself if placed in promiscuous > mode (use sets promisc flag). The other is if vlan filtering is > turned off. Since this is the default configuration, the default > bridge operation is not changed. I like this because it does the right thing and is transparent to the user. You might also not want to do it if the underlying device does not support multiple MAC addresses ie !(dev->priv_flags & IFF_UNICAST_FLT) You could even go into looking at L2 offload on lower device.
