Netdev List
 help / color / mirror / Atom feed
* [PATCH net-next] net: openvswitch: don't schedule rebalancing if there are no datapaths
@ 2026-09-02 20:30 Ilya Maximets
  2026-09-03 10:33 ` Eelco Chaudron
  2026-09-04  0:50 ` patchwork-bot+netdevbpf
  0 siblings, 2 replies; 3+ messages in thread
From: Ilya Maximets @ 2026-09-02 20:30 UTC (permalink / raw)
  To: netdev
  Cc: Aaron Conole, Eelco Chaudron, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Simon Horman, dev, linux-kernel,
	Ilya Maximets

During namespace initialization the masks rebalancing work is
scheduled and automatically re-scheduled every 4 seconds afterwards.
This is happening in every namespace.  On a large kubernetes node with
500 pods, i.e., 500+ namespaces, this creates a decent amount of
unnecessary churn scheduling 500 jobs every 4 seconds that take the
mutex, check that there are no datapaths in their namespace, release
the mutex, re-schedule themselves and exit.  These 500 unnecessary
mutex locks may hold off operations in a single namespace that
actually has a datapath configured and has real user requests to
handle under this lock.  They can also add delay to removal of other
namespaces as ovs_exit_net() needs to take that lock as well and
synchronously waits for the work to be cancelled.

Let's only fire the job when the first datapath is actually created
and not re-arm it if there are no more datapaths configured in the
namespace.

Another approach would be to make ovs_mutex per-namespace, but it's
a much larger change that should be handled separately, and the
unnecessary work scheduling feels like a waste regardless.

It's safe to check and re-arm outside of the mutex as DP_CMD_NEW
handler will re-arm if the new datapath appears.  The scheduling
attempt also doesn't change the work or delay if it is already queued,
so it's also safe to call multiple times.

Skipping the re-arming is more elegant than canceling on removal of
the last datapath as it allows us to not think about potential race
conditions at a negligible cost of potentially one extra re-scheduling.

msecs_to_jiffies() moved to the macro to save on line length.

Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
---
 net/openvswitch/datapath.c | 14 ++++++++++----
 net/openvswitch/datapath.h |  2 +-
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 631a03136fa14..2187034143255 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1921,6 +1921,10 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct genl_info *info)
 
 	ovs_unlock();
 
+	/* Start periodic mask rebalancing if it wasn't already. */
+	schedule_delayed_work(&ovs_net->masks_rebalance,
+			      DP_MASKS_REBALANCE_INTERVAL);
+
 	ovs_notify(&dp_datapath_genl_family, reply, info);
 	return 0;
 
@@ -2598,16 +2602,20 @@ static void ovs_dp_masks_rebalance(struct work_struct *work)
 	struct ovs_net *ovs_net = container_of(work, struct ovs_net,
 					       masks_rebalance.work);
 	struct datapath *dp;
+	bool rearm;
 
 	ovs_lock();
 
 	list_for_each_entry(dp, &ovs_net->dps, list_node)
 		ovs_flow_masks_rebalance(&dp->table);
 
+	rearm = !list_empty(&ovs_net->dps);
+
 	ovs_unlock();
 
-	schedule_delayed_work(&ovs_net->masks_rebalance,
-			      msecs_to_jiffies(DP_MASKS_REBALANCE_INTERVAL));
+	if (rearm)
+		schedule_delayed_work(&ovs_net->masks_rebalance,
+				      DP_MASKS_REBALANCE_INTERVAL);
 }
 
 static const struct nla_policy vport_policy[OVS_VPORT_ATTR_MAX + 1] = {
@@ -2713,8 +2721,6 @@ static int __net_init ovs_init_net(struct net *net)
 	if (err)
 		return err;
 
-	schedule_delayed_work(&ovs_net->masks_rebalance,
-			      msecs_to_jiffies(DP_MASKS_REBALANCE_INTERVAL));
 	return 0;
 }
 
diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
index b2c2b8da12d40..7a7afaeceee5e 100644
--- a/net/openvswitch/datapath.h
+++ b/net/openvswitch/datapath.h
@@ -23,7 +23,7 @@
 
 #define DP_MAX_PORTS                USHRT_MAX
 #define DP_VPORT_HASH_BUCKETS       1024
-#define DP_MASKS_REBALANCE_INTERVAL 4000
+#define DP_MASKS_REBALANCE_INTERVAL msecs_to_jiffies(4000)
 
 /**
  * struct dp_stats_percpu - per-cpu packet processing statistics for a given
-- 
2.55.0


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH net-next] net: openvswitch: don't schedule rebalancing if there are no datapaths
  2026-09-02 20:30 [PATCH net-next] net: openvswitch: don't schedule rebalancing if there are no datapaths Ilya Maximets
@ 2026-09-03 10:33 ` Eelco Chaudron
  2026-09-04  0:50 ` patchwork-bot+netdevbpf
  1 sibling, 0 replies; 3+ messages in thread
From: Eelco Chaudron @ 2026-09-03 10:33 UTC (permalink / raw)
  To: Ilya Maximets
  Cc: netdev, Aaron Conole, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Simon Horman, dev, linux-kernel



On 2 Sep 2026, at 22:30, Ilya Maximets wrote:

> During namespace initialization the masks rebalancing work is
> scheduled and automatically re-scheduled every 4 seconds afterwards.
> This is happening in every namespace.  On a large kubernetes node with
> 500 pods, i.e., 500+ namespaces, this creates a decent amount of
> unnecessary churn scheduling 500 jobs every 4 seconds that take the
> mutex, check that there are no datapaths in their namespace, release
> the mutex, re-schedule themselves and exit.  These 500 unnecessary
> mutex locks may hold off operations in a single namespace that
> actually has a datapath configured and has real user requests to
> handle under this lock.  They can also add delay to removal of other
> namespaces as ovs_exit_net() needs to take that lock as well and
> synchronously waits for the work to be cancelled.
>
> Let's only fire the job when the first datapath is actually created
> and not re-arm it if there are no more datapaths configured in the
> namespace.
>
> Another approach would be to make ovs_mutex per-namespace, but it's
> a much larger change that should be handled separately, and the
> unnecessary work scheduling feels like a waste regardless.
>
> It's safe to check and re-arm outside of the mutex as DP_CMD_NEW
> handler will re-arm if the new datapath appears.  The scheduling
> attempt also doesn't change the work or delay if it is already queued,
> so it's also safe to call multiple times.
>
> Skipping the re-arming is more elegant than canceling on removal of
> the last datapath as it allows us to not think about potential race
> conditions at a negligible cost of potentially one extra re-scheduling.
>
> msecs_to_jiffies() moved to the macro to save on line length.
>
> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>

Thanks for looking into this. The approach seems right to me.
I did some basic testing, and it looks fine to me.

Acked-by: Eelco Chaudron <echaudro@redhat.com>


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH net-next] net: openvswitch: don't schedule rebalancing if there are no datapaths
  2026-09-02 20:30 [PATCH net-next] net: openvswitch: don't schedule rebalancing if there are no datapaths Ilya Maximets
  2026-09-03 10:33 ` Eelco Chaudron
@ 2026-09-04  0:50 ` patchwork-bot+netdevbpf
  1 sibling, 0 replies; 3+ messages in thread
From: patchwork-bot+netdevbpf @ 2026-09-04  0:50 UTC (permalink / raw)
  To: Ilya Maximets
  Cc: netdev, aconole, echaudro, davem, edumazet, kuba, pabeni, horms,
	dev, linux-kernel

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed,  2 Sep 2026 22:30:41 +0200 you wrote:
> During namespace initialization the masks rebalancing work is
> scheduled and automatically re-scheduled every 4 seconds afterwards.
> This is happening in every namespace.  On a large kubernetes node with
> 500 pods, i.e., 500+ namespaces, this creates a decent amount of
> unnecessary churn scheduling 500 jobs every 4 seconds that take the
> mutex, check that there are no datapaths in their namespace, release
> the mutex, re-schedule themselves and exit.  These 500 unnecessary
> mutex locks may hold off operations in a single namespace that
> actually has a datapath configured and has real user requests to
> handle under this lock.  They can also add delay to removal of other
> namespaces as ovs_exit_net() needs to take that lock as well and
> synchronously waits for the work to be cancelled.
> 
> [...]

Here is the summary with links:
  - [net-next] net: openvswitch: don't schedule rebalancing if there are no datapaths
    https://git.kernel.org/netdev/net-next/c/6ebcf5074cff

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-09-04  0:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-02 20:30 [PATCH net-next] net: openvswitch: don't schedule rebalancing if there are no datapaths Ilya Maximets
2026-09-03 10:33 ` Eelco Chaudron
2026-09-04  0:50 ` patchwork-bot+netdevbpf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox