| Message ID | dbd18c8a1171549f8249ac5a8b30b1b5ec88a425.1739294057.git.pabeni@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | f0e70409b7eb0584d451f74db0c72af67b6170b3 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next] net: avoid unconditionally touching sk_tsflags on RX | expand |
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>
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>
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>
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!
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,
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(-)