On Fri, 19 Apr 2013 16:52:44 -0400 Vlad Yasevich <vyasevic@xxxxxxxxxx> wrote: > This series is an almost complete rework of the prior attempt > to make the bridge function in non-promisc mode. In this series > the "promiscuity" of an interface is dynamically determined and > the interface may transition from/to promiscuous mode based on > bridge configuration. > > The series keeps an idea of an "uplink" port. That is still user > designated. > The series also adds a concept of "dynamic" bridge port. This is > the default state of the port and means that the user has not > specified any static FDBs for that port. > Once a user has added a static FDB entry to port and also specified > an "uplink" flag for that FDB, the mac address from that FDB is > added to the bridge hw address list and synched down to uplinks. > "Uplinks" are always considered dynamic ports even if a static entry > has been added for them. > Promiscuity is determined by the number of dynamic ports. If there > are no dynamic ports (i.e all ports have static FDBs set), then we > know all the neighbors and can switch promisc off on all of the ports. > If we have only 1 dynamic port and its an uplink, we can synch all > static hw addresses to this port and mark it non-promisc. > If we have more then 1 dynamic port, then all ports have to be > promiscuouse. > This is the algorith that Michael Tsirkin proposed earlier. > It seems that this bridge with uplink port is just a flavor of macvlan. The only argument you made for not using macvlan is that user scripts are expecting bridge API for setup. Which sounds a lot like the original OVS fake-bridge which was dropped when merged upstream.
