On Monday, March 28, 2016 15:43:21 Roland Volkmann wrote:
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.
Thanks for the clarifications. Given the situation at hand it seem fairly simple to extend the existing logic to prevent re-broadcasting on links without packet loss.
I am fully aware that adding a setting presents itself as the easiest solution but it comes with major drawbacks such as:
* Once exposed interfaces to user space can never be removed. We have to carry this around forever. Thus we need a really good reason to do so. * When we let the user decide to configure $something there is a high chance the setting ends up being misconfigured and causing frustration in the end.
Prevent rebroadcasts when possible to reduce overhead is a good idea. However, I'd like to explore all options to auto-detect whether or not rebroadcasts on the same interface are needed or not. The only case requiring investigation is the 'tinc without forwarding' and 'without meshing' ? Can you provide insights as to what that means and whether or not tinc/fastd 'export' their internal state via an interface flag or something along those lines ?
Cheers, Marek