On 9/19/23 11:12, Johannes Nixdorf wrote:
Add a Kconfig option to configure a default FDB learning limit system
wide, so a distributor building a special purpose kernel can limit all
created bridges by default.
The limit is only a soft default setting and overrideable on a per bridge
basis using netlink.
Signed-off-by: Johannes Nixdorf <jnixdorf-oss@xxxxxx>
---
net/bridge/Kconfig | 13 +++++++++++++
net/bridge/br_device.c | 2 ++
2 files changed, 15 insertions(+)
diff --git a/net/bridge/Kconfig b/net/bridge/Kconfig
index 3c8ded7d3e84..c0d9c08088c4 100644
--- a/net/bridge/Kconfig
+++ b/net/bridge/Kconfig
@@ -84,3 +84,16 @@ config BRIDGE_CFM
Say N to exclude this support and reduce the binary size.
If unsure, say N.
+
+config BRIDGE_DEFAULT_FDB_MAX_LEARNED
+ int "Default FDB learning limit"
+ default 0
+ depends on BRIDGE
+ help
+ Sets a default limit on the number of learned FDB entries on
+ new bridges. This limit can be overwritten via netlink on a
+ per bridge basis.
+
+ The default of 0 disables the limit.
+
+ If unsure, say 0.
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 9a5ea06236bd..3214391c15a0 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -531,6 +531,8 @@ void br_dev_setup(struct net_device *dev)
br->bridge_ageing_time = br->ageing_time = BR_DEFAULT_AGEING_TIME;
dev->max_mtu = ETH_MAX_MTU;
+ br->fdb_max_learned = CONFIG_BRIDGE_DEFAULT_FDB_MAX_LEARNED;
+
br_netfilter_rtable_init(br);
br_stp_timer_init(br);
br_multicast_init(br);
This one I'm not sure about at all. Distributions can just create the
bridge with a predefined limit. This is not flexible and just adds
one more kconfig option that is rather unnecessary. Why having a kconfig
knob is better than bridge creation time limit setting? You still have
to create the bridge, so why not set the limit then?