From: Jason Xing <kerneljasonxing@gmail.com>
To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, dsahern@kernel.org,
willemdebruijn.kernel@gmail.com, willemb@google.com,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
yonghong.song@linux.dev, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
jolsa@kernel.org, shuah@kernel.org, ykolal@fb.com
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
Jason Xing <kerneljasonxing@gmail.com>
Subject: [PATCH bpf-next v13 07/12] bpf: add BPF_SOCK_OPS_TSTAMP_SND_SW_CB callback
Date: Thu, 20 Feb 2025 15:29:35 +0800 [thread overview]
Message-ID: <20250220072940.99994-8-kerneljasonxing@gmail.com> (raw)
In-Reply-To: <20250220072940.99994-1-kerneljasonxing@gmail.com>
Support sw SCM_TSTAMP_SND case for bpf timestamping.
Add a new sock_ops callback, BPF_SOCK_OPS_TSTAMP_SND_SW_CB. This
callback will occur at the same timestamping point as the user
space's software SCM_TSTAMP_SND. The BPF program can use it to
get the same SCM_TSTAMP_SND timestamp without modifying the
user-space application.
Based on this patch, BPF program will get the software
timestamp when the driver is ready to send the skb. In the
sebsequent patch, the hardware timestamp will be supported.
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jason Xing <kerneljasonxing@gmail.com>
---
include/linux/skbuff.h | 2 +-
include/uapi/linux/bpf.h | 4 ++++
net/core/skbuff.c | 9 ++++++++-
tools/include/uapi/linux/bpf.h | 4 ++++
4 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 52f6e033e704..76582500c5ea 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -4568,7 +4568,7 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
static inline void skb_tx_timestamp(struct sk_buff *skb)
{
skb_clone_tx_timestamp(skb);
- if (skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP)
+ if (skb_shinfo(skb)->tx_flags & (SKBTX_SW_TSTAMP | SKBTX_BPF))
skb_tstamp_tx(skb, NULL);
}
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 7bcd8b955598..59adcef3326a 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -7040,6 +7040,10 @@ enum {
* SK_BPF_CB_TX_TIMESTAMPING
* feature is on.
*/
+ BPF_SOCK_OPS_TSTAMP_SND_SW_CB, /* Called when skb is about to send
+ * to the nic when SK_BPF_CB_TX_TIMESTAMPING
+ * feature is on.
+ */
};
/* List of TCP states. There is a build check in net/ipv4/tcp.c to detect
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 3206f7708974..308db7dae1ab 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5557,6 +5557,7 @@ static bool skb_tstamp_tx_report_so_timestamping(struct sk_buff *skb,
}
static void skb_tstamp_tx_report_bpf_timestamping(struct sk_buff *skb,
+ struct skb_shared_hwtstamps *hwtstamps,
struct sock *sk,
int tstype)
{
@@ -5566,6 +5567,11 @@ static void skb_tstamp_tx_report_bpf_timestamping(struct sk_buff *skb,
case SCM_TSTAMP_SCHED:
op = BPF_SOCK_OPS_TSTAMP_SCHED_CB;
break;
+ case SCM_TSTAMP_SND:
+ if (hwtstamps)
+ return;
+ op = BPF_SOCK_OPS_TSTAMP_SND_SW_CB;
+ break;
default:
return;
}
@@ -5586,7 +5592,8 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb,
return;
if (skb_shinfo(orig_skb)->tx_flags & SKBTX_BPF)
- skb_tstamp_tx_report_bpf_timestamping(orig_skb, sk, tstype);
+ skb_tstamp_tx_report_bpf_timestamping(orig_skb, hwtstamps,
+ sk, tstype);
if (!skb_tstamp_tx_report_so_timestamping(orig_skb, hwtstamps, tstype))
return;
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index c3b950325846..1ead1e9d31be 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -7037,6 +7037,10 @@ enum {
* SK_BPF_CB_TX_TIMESTAMPING
* feature is on.
*/
+ BPF_SOCK_OPS_TSTAMP_SND_SW_CB, /* Called when skb is about to send
+ * to the nic when SK_BPF_CB_TX_TIMESTAMPING
+ * feature is on.
+ */
};
/* List of TCP states. There is a build check in net/ipv4/tcp.c to detect
--
2.43.5
next prev parent reply other threads:[~2025-02-20 7:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-20 7:29 [PATCH bpf-next v13 00/12] net-timestamp: bpf extension to equip applications transparently Jason Xing
2025-02-20 7:29 ` [PATCH bpf-next v13 01/12] bpf: add networking timestamping support to bpf_get/setsockopt() Jason Xing
2025-02-20 7:29 ` [PATCH bpf-next v13 02/12] bpf: prepare the sock_ops ctx and call bpf prog for TX timestamping Jason Xing
2025-02-20 7:29 ` [PATCH bpf-next v13 03/12] bpf: prevent unsafe access to the sock fields in the BPF timestamping callback Jason Xing
2025-02-20 7:29 ` [PATCH bpf-next v13 04/12] bpf: disable unsafe helpers in TX timestamping callbacks Jason Xing
2025-02-20 7:29 ` [PATCH bpf-next v13 05/12] net-timestamp: prepare for isolating two modes of SO_TIMESTAMPING Jason Xing
2025-02-20 7:29 ` [PATCH bpf-next v13 06/12] bpf: add BPF_SOCK_OPS_TSTAMP_SCHED_CB callback Jason Xing
2025-02-20 7:29 ` Jason Xing [this message]
2025-02-20 7:29 ` [PATCH bpf-next v13 08/12] bpf: add BPF_SOCK_OPS_TSTAMP_SND_HW_CB callback Jason Xing
2025-02-20 7:29 ` [PATCH bpf-next v13 09/12] bpf: add BPF_SOCK_OPS_TSTAMP_ACK_CB callback Jason Xing
2025-02-20 7:29 ` [PATCH bpf-next v13 10/12] bpf: add BPF_SOCK_OPS_TSTAMP_SENDMSG_CB callback Jason Xing
2025-02-20 7:29 ` [PATCH bpf-next v13 11/12] bpf: support selective sampling for bpf timestamping Jason Xing
2025-02-20 7:29 ` [PATCH bpf-next v13 12/12] selftests/bpf: add simple bpf tests in the tx path for timestamping feature Jason Xing
2025-02-20 15:32 ` [PATCH bpf-next v13 00/12] net-timestamp: bpf extension to equip applications transparently Willem de Bruijn
2025-02-20 23:02 ` Martin KaFai Lau
2025-02-20 23:17 ` Jason Xing
2025-02-20 22:50 ` 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=20250220072940.99994-8-kerneljasonxing@gmail.com \
--to=kerneljasonxing@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
--cc=ykolal@fb.com \
--cc=yonghong.song@linux.dev \
/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;
as well as URLs for NNTP newsgroup(s).