Re: RFC: Should net namespaces scale up (>10k) ?

[Kuniyuki Iwashima <kuniyu@amazon.com>]

+Johannes and wireless ML.

From: Alexandre Ferrieux <alexandre.ferrieux@gmail.com>
Date: Sun, 15 Sep 2024 22:49:22 +0200
> (thanks Simon, reposting with another account to avoid the offending disclaimer)
> 
> Hi,
> 
> Currently, netns don't really scale beyond a few thousands, for
> mundane reasons (see below). But should they ? Is there, in the
> design, an assumption that tens of thousands of network namespaces are
> considered "unreasonable" ?
> 
> A typical use case for such ridiculous numbers is a tester for
> firewalls or carrier-grade NATs. In these, you typically want tens of
> thousands of tunnels, each of which is perfectly instantiated as an
> interface. And, to avoid an explosion in source routing rules, you
> want them in separate namespaces.
> 
> Now why don't they scale *today* ? For two independent, seemingly
> accidental, O(N) scans of the netns list.
> 
> 1. The "netdevice notifier" from the Wireless Extensions subsystem
> insists on scanning the whole list regardless of the nature of the
> change, nor wondering whether all these namespaces hold any wireless
> interface, nor even whether the system has _any_ wireless hardware...
> 
>         for_each_net(net) {
>                 while ((skb = skb_dequeue(&net->wext_nlevents)))
>                         rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL,
>                                     GFP_KERNEL);
>         }
>

Alex forwarded this mail to me and asked about 1.

I checked 8bf862739a778, but I didn't see why wext_netdev_notifier_call()
needs to iterate all netns.

Is there a case where flushing messages in the notified dev's netns is not
enough for wext dev ?

---8<---
diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
index 838ad6541a17..d4b613fc650c 100644
--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -343,17 +343,22 @@ static const int compat_event_type_size[] = {
 
 /* IW event code */
 
-void wireless_nlevent_flush(void)
+static void wireless_nlevent_flush_net(struct net *net)
 {
 	struct sk_buff *skb;
+
+	while ((skb = skb_dequeue(&net->wext_nlevents)))
+		rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL,
+			    GFP_KERNEL);
+}
+
+void wireless_nlevent_flush(void)
+{
 	struct net *net;
 
 	down_read(&net_rwsem);
-	for_each_net(net) {
-		while ((skb = skb_dequeue(&net->wext_nlevents)))
-			rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL,
-				    GFP_KERNEL);
-	}
+	for_each_net(net)
+		wireless_nlevent_flush_net(net);
 	up_read(&net_rwsem);
 }
 EXPORT_SYMBOL_GPL(wireless_nlevent_flush);
@@ -361,6 +366,8 @@ EXPORT_SYMBOL_GPL(wireless_nlevent_flush);
 static int wext_netdev_notifier_call(struct notifier_block *nb,
 				     unsigned long state, void *ptr)
 {
+	struct net_device *dev = netdev_notifier_info_to_dev(ptr);
+
 	/*
 	 * When a netdev changes state in any way, flush all pending messages
 	 * to avoid them going out in a strange order, e.g. RTM_NEWLINK after
@@ -368,7 +375,7 @@ static int wext_netdev_notifier_call(struct notifier_block *nb,
 	 * or similar - all of which could otherwise happen due to delays from
 	 * schedule_work().
 	 */
-	wireless_nlevent_flush();
+	wireless_nlevent_flush_net(dev_net(dev));
 
 	return NOTIFY_OK;
 }
---8<---