On 04/30/2014 01:22 PM, Stephen Hemminger wrote: > 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. > Hmm. dev_uc_add() would already take care of that, but yes, we could optimized it a bit more by looking at the flag as well and not bother with the overhead if the device will just function in promiscuous mode anyway. -vlad
