On Tue, Aug 22, 2017 at 02:01:40PM +0300, Nikolay Aleksandrov wrote: > On 22/08/17 03:01, Stephen Hemminger wrote: > > I know the bridge is an easy target to extend L2 forwarding, but it is not > > the only option. Have you condidered building a new driver (like VXLAN does) > > which does the forwarding you want. Having all features in one driver > > makes for worse performance, and increased complexity. > > > > +1 > > As I said before, a separate implementation will be much cleaner and will not > affect > the bridge in any way, paying both performance and complexity price for > something that > the majority of users will not be using isn't worth it. In addition this > creates a > silent dependency between the bridge and the fdb metadata dst users, it would > be much > more preferable to be able to run them separately. > If there is any code that will need to be re-used by VPLS (or anyone else) > figure out a way > to factor it out.
Could you tell me why this argument didn't apply to the bridge vlan tunnel code? It adds complexity to the bridge specifically for VXLAN (and it does *not* transfer to VPLS or 802.11) and reduces performance ... by actually accessing the same metadata that this patchset does. -David
