public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Kuniyuki Iwashima <kuniyu@google.com>
To: "David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>
Cc: Simon Horman <horms@kernel.org>,
	Kuniyuki Iwashima <kuniyu@google.com>,
	 Kuniyuki Iwashima <kuni1840@gmail.com>,
	netdev@vger.kernel.org
Subject: [PATCH v1 net-next 15/15] udp_tunnel: Remove synchronize_rcu() in udp_tunnel_sock_release().
Date: Sat,  2 May 2026 03:13:08 +0000	[thread overview]
Message-ID: <20260502031401.3557229-16-kuniyu@google.com> (raw)
In-Reply-To: <20260502031401.3557229-1-kuniyu@google.com>

Commit 3cf7203ca620 ("net/tunnel: wait until all sk_user_data
reader finish before releasing the sock") added synchronize_rcu()
in udp_tunnel_sock_release().

This was intended to protect the fast path of a dying vxlan device
from dereferencing vxlan_sock->sock->sk after sock_orphan() has set
sock->sk to NULL.

However, vxlan does not need to access struct socket itself
in the fast path; it only reads struct sock, and struct socket
is only used for tunnel setup and teardown.

This applies to all other UDP tunnel users, and they have been
converted to access struct sock directly.

In addition, each device-specific struct used in their fast paths
is freed after one RCU grace period.  Since this occurs after
udp_tunnel_sock_release(), the struct is guaranteed to be freed
after struct udp_sock.

Therefore, synchronize_rcu() in udp_tunnel_sock_release() is
now redundant.

Let's remove it.

Tested:

A script creating/upping vxlan devices in 4000 netns runs 10x
faster with this change.  We can see the same improvement with
other UDP tunnel devices as well.

  $ cat vxlan.sh
  for i in `seq 1 40`
  do
      (for j in `seq 1 100` ; do
            unshare -n bash -c "ip link add vxlan0 type vxlan id 100 local 127.0.0.1 dstport 4789 && ip link set vxlan0 up";
       done) &
  done
  wait

With bpftrace, we can see vxlan_stop() is significantly faster.

  bpftrace -e '
  kprobe:vxlan_stop {
          @start[tid] = nsecs;
  }

  kretprobe:vxlan_stop /@start[tid]/ {
          @duration_us = hist((nsecs - @start[tid]) / 1000);
          delete(@start[tid]);
  }

  END {
          printf("\nExecution time of vxlan_stop (us):\n");
  }'

Before:

  # time ./vxlan.sh // without bpftrace
  real	0m50.615s
  user	0m8.171s
  sys	1m45.101s

  @duration_us:
  [4K, 8K)            1266 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@                   |
  [8K, 16K)           1957 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
  [16K, 32K)           764 |@@@@@@@@@@@@@@@@@@@@                                |
  [32K, 64K)             6 |                                                    |
  [64K, 128K)            4 |                                                    |
  [128K, 256K)           3 |                                                    |

After:

  # time ./vxlan.sh // without bpftrace
  real	0m5.247s
  user	0m7.956s
  sys	1m47.404s

  @duration_us:
  [16, 32)            3411 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
  [32, 64)             383 |@@@@@                                               |
  [64, 128)            107 |@                                                   |
  [128, 256)            79 |@                                                   |
  [256, 512)            16 |                                                    |
  [512, 1K)              2 |                                                    |
  [1K, 2K)               2 |                                                    |

Next step is to remove another synchronize_net() in vxlan_stop()
and variants in other devices.

Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
 net/ipv4/udp_tunnel_core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c
index 44788b95c823..9ab3728f9630 100644
--- a/net/ipv4/udp_tunnel_core.c
+++ b/net/ipv4/udp_tunnel_core.c
@@ -194,7 +194,6 @@ void udp_tunnel_sock_release(struct sock *sk)
 	struct socket *sock = sk->sk_socket;
 
 	rcu_assign_sk_user_data(sk, NULL);
-	synchronize_rcu();
 	kernel_sock_shutdown(sock, SHUT_RDWR);
 	sock_release(sock);
 }
-- 
2.54.0.545.g6539524ca2-goog


  parent reply	other threads:[~2026-05-02  3:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-02  3:12 [PATCH v1 net-next 00/15] udp_tunnel: Speed up UDP tunnel device destruction (Part I) Kuniyuki Iwashima
2026-05-02  3:12 ` [PATCH v1 net-next 01/15] udp_tunnel: Pass struct sock to udp_tunnel_sock_release() Kuniyuki Iwashima
2026-05-03 18:43   ` Kuniyuki Iwashima
2026-05-02  3:12 ` [PATCH v1 net-next 02/15] udp_tunnel: Pass struct sock to setup_udp_tunnel_sock() Kuniyuki Iwashima
2026-05-02  3:12 ` [PATCH v1 net-next 03/15] udp_tunnel: Pass struct sock to udp_tunnel6_dst_lookup() Kuniyuki Iwashima
2026-05-02  3:12 ` [PATCH v1 net-next 04/15] udp_tunnel: Pass struct sock to udp_tunnel_{push,drop}_rx_port() Kuniyuki Iwashima
2026-05-02  3:12 ` [PATCH v1 net-next 05/15] udp_tunnel: Pass struct sock to udp_tunnel_notify_{add,del}_rx_port() Kuniyuki Iwashima
2026-05-02  3:12 ` [PATCH v1 net-next 06/15] vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive() Kuniyuki Iwashima
2026-05-02  3:13 ` [PATCH v1 net-next 07/15] vxlan: Store struct sock in struct vxlan_sock Kuniyuki Iwashima
2026-05-02  3:13 ` [PATCH v1 net-next 08/15] vxlan: Free vxlan_sock with kfree_rcu() Kuniyuki Iwashima
2026-05-02  3:13 ` [PATCH v1 net-next 09/15] geneve: Store struct sock in struct geneve_sock Kuniyuki Iwashima
2026-05-02  3:13 ` [PATCH v1 net-next 10/15] bareudp: Store struct sock in struct bareudp_dev Kuniyuki Iwashima
2026-05-03 18:47   ` Kuniyuki Iwashima
2026-05-02  3:13 ` [PATCH v1 net-next 11/15] fou: Store struct sock in struct fou Kuniyuki Iwashima
2026-05-03 18:52   ` Kuniyuki Iwashima
2026-05-02  3:13 ` [PATCH v1 net-next 12/15] amt: Store struct sock in struct amt_dev Kuniyuki Iwashima
2026-05-03 18:55   ` Kuniyuki Iwashima
2026-05-02  3:13 ` [PATCH v1 net-next 13/15] pfcp: Store struct sock in struct pfcp_dev Kuniyuki Iwashima
2026-05-03 19:00   ` Kuniyuki Iwashima
2026-05-02  3:13 ` [PATCH v1 net-next 14/15] tipc: Store struct sock in struct udp_bearer Kuniyuki Iwashima
2026-05-03 19:05   ` Kuniyuki Iwashima
2026-05-02  3:13 ` Kuniyuki Iwashima [this message]
2026-05-06  0:49 ` [PATCH v1 net-next 00/15] udp_tunnel: Speed up UDP tunnel device destruction (Part I) Jakub Kicinski
2026-05-06  1:43   ` Kuniyuki Iwashima
2026-05-06  1:00 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260502031401.3557229-16-kuniyu@google.com \
    --to=kuniyu@google.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuni1840@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox