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

["Nicolas Escande" <nico.escande@gmail.com>]

On Thu Nov 14, 2024 at 7:06 PM CET, Linus Lüssing wrote:
> Hi Nicolas,
>
> Many thanks for your feedback!
>
[...]
>
> > >
> > > 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?
>
I really like this idea. This either could be a compile time knob or a dynamic
one to ensure we don't easilly have a too big OGM

> ---
>
> 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

Thanks