Re: [PATCH net-next v2] bridge: Synchronize unicast filtering with FDB

From: Nikolay Aleksandrov <redacted>
Date: Sat, 11 Jun 2016 18:17:53 +0200

Oops, I almost missed the v2, sorry about that. So, technically it
looks correct, but I only fear the scalability impact of the
change. If there're a large number of vlans adding a macvlan (or any
device that syncs uc addr) might become very slow and every flag
change will become very slow too without an option to revert to the
original behaviour so we'll have to wait for the entries to be added
in order to delete them.  Another common scenario is having 8021q
interfaces on top of the bridge with different mac addresses for
some of the configured vlans (or with macvlans on top of them for
VRR), that use case would suffer as well because their macs need to
be local only for those vlans, and not the 2000+ other vlans that
might exist.  On every sync_uc() call all the fdb entries get
deleted and added again, so even after deleting some manually they
can come back unexpectedly after some operation and also the message
storm from all the deletes and adds could be problematic as well.


E.g. 2000 br0 vlans, 25 macvlans on br0 (adding them took more than 5 minutes, 53k fdb entries):
$ bridge fdb del de:8e:9f:16:c5:71 dev br0 vlan 289
$ ip l set br0 multicast on
$ bridge fdb | grep 289 | grep de:8e:9f:16:c5:71
de:8e:9f:16:c5:71 dev br0 vlan 1289 master br0 permanent
de:8e:9f:16:c5:71 dev br0 vlan 289 master br0 permanent

In fact you can't escape the slow performance even if you delete all
entries because on the next flag change or interface add, they will
be added back.

Yeah, I think the performance implications are too severe too, I'm
not applying this.