[PATCH net-next] net: avoid unconditionally touching sk_tsflags on RX

[PATCH net-next] net: avoid unconditionally touching sk_tsflags on RX

[Paolo Abeni]

After commit 5d4cc87414c5 ("net: reorganize "struct sock" fields"),
the sk_tsflags field shares the same cacheline with sk_forward_alloc.

The UDP protocol does not acquire the sock lock in the RX path;
forward allocations are protected via the receive queue spinlock;
additionally udp_recvmsg() calls sock_recv_cmsgs() unconditionally
touching sk_tsflags on each packet reception.

Due to the above, under high packet rate traffic, when the BH and the
user-space process run on different CPUs, UDP packet reception
experiences a cache miss while accessing sk_tsflags.

The receive path doesn't strictly need to access the problematic field;
change sock_set_timestamping() to maintain the relevant information
in a newly allocated sk_flags bit, so that sock_recv_cmsgs() can
take decisions accessing the latter field only.

With this patch applied, on an AMD epic server with i40e NICs, I
measured a 10% performance improvement for small packets UDP flood
performance tests - possibly a larger delta could be observed with more
recent H/W.

Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
 include/net/sock.h | 9 +++++----
 net/core/sock.c    | 1 +
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index 8036b3b79cd8..60ebf3c7b229 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -954,6 +954,7 @@ enum sock_flags {
 	SOCK_TSTAMP_NEW, /* Indicates 64 bit timestamps always */
 	SOCK_RCVMARK, /* Receive SO_MARK  ancillary data with packet */
 	SOCK_RCVPRIORITY, /* Receive SO_PRIORITY ancillary data with packet */
+	SOCK_TIMESTAMPING_ANY, /* Copy of sk_tsflags & TSFLAGS_ANY */
 };
 
 #define SK_FLAGS_TIMESTAMP ((1UL << SOCK_TIMESTAMP) | (1UL << SOCK_TIMESTAMPING_RX_SOFTWARE))
@@ -2664,13 +2665,13 @@ static inline void sock_recv_cmsgs(struct msghdr *msg, struct sock *sk,
 {
 #define FLAGS_RECV_CMSGS ((1UL << SOCK_RXQ_OVFL)			| \
 			   (1UL << SOCK_RCVTSTAMP)			| \
-			   (1UL << SOCK_RCVMARK)			|\
-			   (1UL << SOCK_RCVPRIORITY))
+			   (1UL << SOCK_RCVMARK)			| \
+			   (1UL << SOCK_RCVPRIORITY)			| \
+			   (1UL << SOCK_TIMESTAMPING_ANY))
 #define TSFLAGS_ANY	  (SOF_TIMESTAMPING_SOFTWARE			| \
 			   SOF_TIMESTAMPING_RAW_HARDWARE)
 
-	if (sk->sk_flags & FLAGS_RECV_CMSGS ||
-	    READ_ONCE(sk->sk_tsflags) & TSFLAGS_ANY)
+	if (READ_ONCE(sk->sk_flags) & FLAGS_RECV_CMSGS)
 		__sock_recv_cmsgs(msg, sk, skb);
 	else if (unlikely(sock_flag(sk, SOCK_TIMESTAMP)))
 		sock_write_timestamp(sk, skb->tstamp);
diff --git a/net/core/sock.c b/net/core/sock.c
index eae2ae70a2e0..a197f0a0b878 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -938,6 +938,7 @@ int sock_set_timestamping(struct sock *sk, int optname,
 
 	WRITE_ONCE(sk->sk_tsflags, val);
 	sock_valbool_flag(sk, SOCK_TSTAMP_NEW, optname == SO_TIMESTAMPING_NEW);
+	sock_valbool_flag(sk, SOCK_TIMESTAMPING_ANY, !!(val & TSFLAGS_ANY));
 
 	if (val & SOF_TIMESTAMPING_RX_SOFTWARE)
 		sock_enable_timestamp(sk,
-- 
2.48.1

Re: [PATCH net-next] net: avoid unconditionally touching sk_tsflags on RX

[Eric Dumazet]

On Tue, Feb 11, 2025 at 6:17 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> After commit 5d4cc87414c5 ("net: reorganize "struct sock" fields"),
> the sk_tsflags field shares the same cacheline with sk_forward_alloc.
>
> The UDP protocol does not acquire the sock lock in the RX path;
> forward allocations are protected via the receive queue spinlock;
> additionally udp_recvmsg() calls sock_recv_cmsgs() unconditionally
> touching sk_tsflags on each packet reception.
>
> Due to the above, under high packet rate traffic, when the BH and the
> user-space process run on different CPUs, UDP packet reception
> experiences a cache miss while accessing sk_tsflags.
>
> The receive path doesn't strictly need to access the problematic field;
> change sock_set_timestamping() to maintain the relevant information
> in a newly allocated sk_flags bit, so that sock_recv_cmsgs() can
> take decisions accessing the latter field only.
>
> With this patch applied, on an AMD epic server with i40e NICs, I
> measured a 10% performance improvement for small packets UDP flood
> performance tests - possibly a larger delta could be observed with more
> recent H/W.
>
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Thanks a lot Paolo

Reviewed-by: Eric Dumazet <edumazet@google.com>

Re: [PATCH net-next] net: avoid unconditionally touching sk_tsflags on RX

[Willem de Bruijn]

Paolo Abeni wrote:
> After commit 5d4cc87414c5 ("net: reorganize "struct sock" fields"),
> the sk_tsflags field shares the same cacheline with sk_forward_alloc.
> 
> The UDP protocol does not acquire the sock lock in the RX path;
> forward allocations are protected via the receive queue spinlock;
> additionally udp_recvmsg() calls sock_recv_cmsgs() unconditionally
> touching sk_tsflags on each packet reception.
> 
> Due to the above, under high packet rate traffic, when the BH and the
> user-space process run on different CPUs, UDP packet reception
> experiences a cache miss while accessing sk_tsflags.
> 
> The receive path doesn't strictly need to access the problematic field;
> change sock_set_timestamping() to maintain the relevant information
> in a newly allocated sk_flags bit, so that sock_recv_cmsgs() can
> take decisions accessing the latter field only.
> 
> With this patch applied, on an AMD epic server with i40e NICs, I
> measured a 10% performance improvement for small packets UDP flood
> performance tests - possibly a larger delta could be observed with more
> recent H/W.
> 
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Reviewed-by: Willem de Bruijn <willemb@google.com>

Re: [PATCH net-next] net: avoid unconditionally touching sk_tsflags on RX

[Kuniyuki Iwashima]

From: Paolo Abeni <pabeni@redhat.com>
Date: Tue, 11 Feb 2025 18:17:31 +0100
> After commit 5d4cc87414c5 ("net: reorganize "struct sock" fields"),
> the sk_tsflags field shares the same cacheline with sk_forward_alloc.
> 
> The UDP protocol does not acquire the sock lock in the RX path;
> forward allocations are protected via the receive queue spinlock;
> additionally udp_recvmsg() calls sock_recv_cmsgs() unconditionally
> touching sk_tsflags on each packet reception.
> 
> Due to the above, under high packet rate traffic, when the BH and the
> user-space process run on different CPUs, UDP packet reception
> experiences a cache miss while accessing sk_tsflags.
> 
> The receive path doesn't strictly need to access the problematic field;
> change sock_set_timestamping() to maintain the relevant information
> in a newly allocated sk_flags bit, so that sock_recv_cmsgs() can
> take decisions accessing the latter field only.
> 
> With this patch applied, on an AMD epic server with i40e NICs, I
> measured a 10% performance improvement for small packets UDP flood
> performance tests - possibly a larger delta could be observed with more
> recent H/W.
> 
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>

Re: [PATCH net-next] net: avoid unconditionally touching sk_tsflags on RX

[patchwork-bot+netdevbpf]

Hello:

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

On Tue, 11 Feb 2025 18:17:31 +0100 you wrote:
> After commit 5d4cc87414c5 ("net: reorganize "struct sock" fields"),
> the sk_tsflags field shares the same cacheline with sk_forward_alloc.
> 
> The UDP protocol does not acquire the sock lock in the RX path;
> forward allocations are protected via the receive queue spinlock;
> additionally udp_recvmsg() calls sock_recv_cmsgs() unconditionally
> touching sk_tsflags on each packet reception.
> 
> [...]

Here is the summary with links:
  - [net-next] net: avoid unconditionally touching sk_tsflags on RX
    https://git.kernel.org/netdev/net-next/c/f0e70409b7eb

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