Re: [PATCH v2] batman-adv: add dynamic, bridged-in TT VID detection support

["Linus Lüssing" <linus.luessing@c0d3.blue>]

Hi Nicolas,

Many thanks for your feedback!

On Thu, Nov 14, 2024 at 03:53:11PM +0100, Nicolas Escande wrote:
> On Thu Nov 14, 2024 at 2:58 PM CET, Sven Eckelmann wrote:
> > On Thursday, 14 November 2024 14:48:52 CET Nicolas Escande wrote:
> > > Hi there,
> > > 
> > > We've been running this for a few time and it's very usefull. So is there any
> > > news on merging this into the kernel ? Or is the BLA thing blocking ?

Yes, I think this is at least one of the blocking issues. I didn't
quite get my head fully wrapped around the BLA code yet.
(Any help/guidance still appreciated :D. BLA is the one code part,
other than network coding, that I haven't really looked into and digested
so far. And what clashes right now is a specific internal that
isn't fully documented on the BLA wiki pages, unless I overlooked
it?)

> >
> > I am not in favour of changing the behavior of batman-adv. Now everyone can 
> > increase the number of managed VLANs without any control by the node admin.

Valid concern. Especially as each added VLAN is quite costly for
an OGM at the moment. A VLAN with one MAC address adds 12 bytes to
a 24 bytes base OGM IV length (excluding ethernet header and other
TVLVs).

However in a way for non-VLAN TT entries this is also partially a concern,
right? Someone could also flood source MAC addresses in an uncontrolled
way, too. (Though would likely have to actively keep roaming to create a
constant extra overhead.)

Maybe it would make sense to check how the Linux bridge approaches
this?

It seems there is an admin configurable limit of
BR_MULTICAST_DEFAULT_HASH_MAX = 4096 entries for the MDB
(multicast MAC addresses).
And a configurable fdb_max_learned (disabled by default, for
backwards compatibility reasons according to bdb4dfda3b) for the
FDB (unicast MAC addresse).
Thirdly, it seems 4096 VLANs are allowed (VLAN_N_VID), the maximum
amount. Though this one does not seem configurable.

Would it maybe make sense to have a knob and by default set the
limit to 8 or 16 VLANs? A default which could maybe be increased if the
OGM size was decoupled from the amount of VLANs in the future?

---

The two reasons I would like to have a dynamic VLAN feature,
especially for wireless community mesh networks:

Allow a group of people to setup and use their own address space
when the centrally managed, default one does not match their
needs. -> decentralization

Allow to get rid of the unused VID=0 and VID=1 entries by default,
only dynamically learn them, to typically reduce the OGM overhead
by at least 2*12 bytes. To partially mitigate the overhead regression
we introduced by adding TT in compat 15.

---

Just my overall, conceptual thoughts on this feature. Will look into the
refcount issue later, thanks for reporting!

Regards, Linus