tree 686df3c240a48183eaf71f50a117ddcd15f121aa
parent 8c9190bfd18a2548dea677faed7d6ee11f3cb0c8
author Ilya Maximets <i.maximets@ovn.org> 1788381041 +0200
committer Jakub Kicinski <kuba@kernel.org> 1788482803 -0700

net: openvswitch: don't schedule rebalancing if there are no datapaths

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>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Link: https://patch.msgid.link/20260902203200.1416026-1-i.maximets@ovn.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>