From: Martin KaFai Lau <martin.lau@linux.dev>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: 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,
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, horms@kernel.org,
bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next v9 02/12] bpf: prepare for timestamping callbacks use
Date: Mon, 10 Feb 2025 17:31:50 -0800 [thread overview]
Message-ID: <fb1111fc-6a4e-4388-860c-0077910e814f@linux.dev> (raw)
In-Reply-To: <20250208103220.72294-3-kerneljasonxing@gmail.com>
On 2/8/25 2:32 AM, Jason Xing wrote:
> Later, four callback points to report information to user space
> based on this patch will be introduced.
>
> As to skb initialization here, users can follow these three steps
> as below to fetch the shared info from the exported skb in the bpf
> prog:
> 1. skops_kern = bpf_cast_to_kern_ctx(skops);
> 2. skb = skops_kern->skb;
> 3. shinfo = bpf_core_cast(skb->head + skb->end, struct skb_shared_info);
>
> More details can be seen in the last selftest patch of the series.
This BPF program example is not useful in this commit message. It is not how
this change will be used in the kernel. People will naturally be required to
look at the selftest to see how the bpf prog can get to the skb and tskey, etc.
The commit message should focus on explaining "what" has changed and "why" it is
necessary. The "why" part ("four callback points to report...") is mostly
present but could be clearer.
Subject: bpf: Prepare the sock_ops ctx and call bpf prog for TX timestamping
(What)
This patch introduces a new bpf_skops_tx_timestamping() function that prepares
the "struct bpf_sock_ops" ctx and then executes the sockops BPF program.
(Why)
The subsequent patch will utilize bpf_skops_tx_timestamping() at the existing TX
timestamping kernel callbacks (__sk_tstamp_tx specifically) to call the sockops
BPF program.
>
> Signed-off-by: Jason Xing <kerneljasonxing@gmail.com>
> ---
> include/net/sock.h | 7 +++++++
> net/core/sock.c | 15 +++++++++++++++
> 2 files changed, 22 insertions(+)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 7916982343c6..6f4d54faba92 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -2923,6 +2923,13 @@ int sock_set_timestamping(struct sock *sk, int optname,
> struct so_timestamping timestamping);
>
> void sock_enable_timestamps(struct sock *sk);
> +#if defined(CONFIG_CGROUP_BPF)
> +void bpf_skops_tx_timestamping(struct sock *sk, struct sk_buff *skb, int op);
> +#else
> +static inline void bpf_skops_tx_timestamping(struct sock *sk, struct sk_buff *skb, int op)
> +{
> +}
> +#endif
> void sock_no_linger(struct sock *sk);
> void sock_set_keepalive(struct sock *sk);
> void sock_set_priority(struct sock *sk, u32 priority);
> diff --git a/net/core/sock.c b/net/core/sock.c
> index eae2ae70a2e0..41db6407e360 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -948,6 +948,21 @@ int sock_set_timestamping(struct sock *sk, int optname,
> return 0;
> }
>
> +#if defined(CONFIG_CGROUP_BPF)
> +void bpf_skops_tx_timestamping(struct sock *sk, struct sk_buff *skb, int op)
> +{
> + struct bpf_sock_ops_kern sock_ops;
> +
> + memset(&sock_ops, 0, offsetof(struct bpf_sock_ops_kern, temp));
> + sock_ops.op = op;
> + sock_ops.is_fullsock = 1;
> + sock_ops.sk = sk;
> + bpf_skops_init_skb(&sock_ops, skb, 0);
> + /* Timestamping bpf extension supports only TCP and UDP full socket */
nit: After our earlier discussions, it's clear that the above is_fullsock = 1;
is always true for all sk here. This comment has become redundant. Let's remove it.
> + __cgroup_bpf_run_filter_sock_ops(sk, &sock_ops, CGROUP_SOCK_OPS);
> +}
> +#endif
> +
> void sock_set_keepalive(struct sock *sk)
> {
> lock_sock(sk);
next prev parent reply other threads:[~2025-02-11 1:31 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-08 10:32 [PATCH bpf-next v9 00/12] net-timestamp: bpf extension to equip applications transparently Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 01/12] bpf: add support for bpf_setsockopt() Jason Xing
2025-02-11 1:02 ` Martin KaFai Lau
2025-02-11 2:24 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 02/12] bpf: prepare for timestamping callbacks use Jason Xing
2025-02-11 1:31 ` Martin KaFai Lau [this message]
2025-02-11 2:25 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 03/12] bpf: stop unsafely accessing TCP fields in bpf callbacks Jason Xing
2025-02-11 6:34 ` Martin KaFai Lau
2025-02-11 8:08 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 04/12] bpf: stop calling some sock_op BPF CALLs in new timestamping callbacks Jason Xing
2025-02-11 6:55 ` Martin KaFai Lau
2025-02-11 8:24 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 05/12] net-timestamp: prepare for isolating two modes of SO_TIMESTAMPING Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 06/12] bpf: support SCM_TSTAMP_SCHED " Jason Xing
2025-02-11 7:12 ` Martin KaFai Lau
2025-02-11 7:31 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 07/12] bpf: support sw SCM_TSTAMP_SND " Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 08/12] bpf: support hw " Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 09/12] bpf: support SCM_TSTAMP_ACK " Jason Xing
2025-02-08 17:54 ` Willem de Bruijn
2025-02-08 23:27 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 10/12] bpf: add a new callback in tcp_tx_timestamp() Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 11/12] bpf: support selective sampling for bpf timestamping Jason Xing
2025-02-11 7:41 ` Martin KaFai Lau
2025-02-11 7:48 ` Jason Xing
2025-02-08 10:32 ` [PATCH bpf-next v9 12/12] selftests/bpf: add simple bpf tests in the tx path for timestamping feature Jason Xing
2025-02-11 8:05 ` Martin KaFai Lau
2025-02-11 11:37 ` Jason Xing
2025-02-10 23:37 ` [PATCH bpf-next v9 00/12] net-timestamp: bpf extension to equip applications transparently Martin KaFai Lau
2025-02-11 0:03 ` Jason Xing
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=fb1111fc-6a4e-4388-860c-0077910e814f@linux.dev \
--to=martin.lau@linux.dev \
--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=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.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).