Hi Marek,
if you are advocating in favor of this patch I see no real need to wait for Linus. Maybe you can help us understand what this patch does and why it is useful. These were the questions raised in https://patchwork.open-mesh.org/patch/4384/ and remain unanswered till today.
I am also unclear why this old patch is re-hashed once more since we merged a patch 3 years ago achieving the same goal without a manual knob. Can somebody shed some light on this ?
The patch in question: commit cc1fde312b6d3c010784a80aff9e942e3b16d015 Author: Matthias Schiffer mschiffer@universe-factory.net Date: Sat Mar 9 23:14:23 2013 +0100 Subject: batman-adv: send each broadcast only once on non-wireless interfaces
this patch/commit addresses another issue than the "new" request 4384: it limits the number of broadcasts to be transmitted on an interface, with the limit automatically adjusting depending of type of interface.
Request 4384 allows to suppress broadcast packets completely on the interface, where the node has received them (no rebroadcast). This is typical behavior of physical switches, where broadcasts are sent out to all ports except the one, where the packet was received.
In Freifunk-Environments we have various types of links, and you cannot determine automatically the interfaces, where you need rebroadcast and where rebroadcasts should be suppressed. Some examples:
When having Nodes meshing on WLAN (one WLAN Interface per Node) you need rebroadcasts. If using fastd-VPN connections or tinc without forwarding enabled and without full meshing you also need rebroadcast.
But when connecting nodes with LAN-Cable and physical switch, or using tinc with forwarding enabled, or having point-to-point connections, especially WiFi longshots or PowerLAN-Adapters or other low bandwidth connections, the rebroadcasts will waste bandwith and/or air time.
Therefore we would prefer to have this setting as a manual setting, default to rebroadcast being enabled.
This patch is present in Gluon for quite some time now and considered stable. In practice we can save significant bandwith and ressources on the Nodes in local mesh clouds having mesh-on-lan with multiple nodes (and clients). Because of this experience on non-gateway nodes we also want to use this feature on gateways without gluon, if multiple gateways are meshed.
If you need more information, please let me know.
Best regards, Roland.