On Tue, Aug 22, 2017 at 02:55:04PM +0300, Nikolay Aleksandrov wrote: > On 22/08/17 14:32, David Lamparter wrote: > > 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. > > The separation is clean and does not add any dependencies, that code > is well isolated. As for performance, the impact is minimal as it > adds a test for a port flag that is already in the cache at that > point. Ah, ok, now this is useful input... I can add a BR_PORT_METADATA flag. > In fact it can be compiled-out entirely if you disable bridge vlan > support. The metadata you're referring to is not accessed if the port > flag is not set or vlan support is compiled out removing its impact > entirely. Ok, I can probably adapt this patchset to do the same. > You can have a vxlan setup without bridge, no ? You can run the VPLS code without a bridge too... behaviour will be the same as with other ip tunnels when you set the destination to multicast (packets get flooded.) -David
