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