On Mon, Aug 21, 2017 at 05:01:51PM -0700, Stephen Hemminger wrote:

On Mon, 21 Aug 2017 19:15:17 +0200 David Lamparter [off-list ref] wrote:

quoted

quoted

P.S.: For a little context on the bridge FDB changes - I'm hoping to
find some time to extend this to the MDB to allow aggregating dst
metadata and handing down a list of dst metas on TX.  This isn't
specifically for VPLS but rather to give sufficient information to the
802.11 stack to allow it to optimize selecting rates (or unicasting)
for multicast traffic by having the multicast subscriber list known.
This is done by major commercial wifi solutions (e.g. google "dynamic
multicast optimization".)  

You can find hacks at this on:
https://github.com/eqvinox/vpls-linux-kernel/tree/mdb-hack
Please note that the patches in that branch are not at an acceptable
quality level, but you can see the semantic relation to 802.11.

I would, however, like to point out that this branch has pseudo-working
IGMP/MLD snooping for VPLS, and it'd be 20-ish lines to add it to NVGRE
(I'll do that as soon as I get to it, it'll pop up on that branch too.)

This is relevant to the discussion because it's a feature which is
non-obvious (to me) on how to do with the VXLAN model of having an
entirely separate FDB.  Meanwhile, with this architecture, the proof of
concept / hack is coming in at a measly cost of:
8 files changed, 176 insertions(+), 15 deletions(-)

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

Yes I have;  I dismissed the approach because even though an fdb is
reasonable to duplicate, I did not believe replicating multicast
snooping code into both VPLS and 802.11 (and possibly VXLAN) to be a
viable option.  ...is it?

(like VXLAN does) which does the forwarding you want. Having all
features in one driver makes for worse performance, and increased
complexity.

Can you elaborate?  I agree with that sentence as a general statement,
but a general statement needs to apply to a specific situation.  As
discussed in the previous thread with Nikolay, checking skb->_refdst
against 0 should be doable without touching additional cachelines, so
the performance cost should be rather small.  For complexity - it's
keeping an extra pointer around, which is semantically bound to the
existing net_bridge_fdb_entry->dst.  On the other hand, it spares us
from another copy of a fdb implementation, and two copies of multicast
snooping code...  I honestly believe this patchset is a good approach.


-David