[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d2605829-d5c2-4ce2-ac27-9f1df0398ccc@linux.dev>
Date: Mon, 3 Feb 2025 17:16:24 -0800
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, dsahern@...nel.org, willemdebruijn.kernel@...il.com,
willemb@...gle.com, ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
eddyz87@...il.com, song@...nel.org, yonghong.song@...ux.dev,
john.fastabend@...il.com, kpsingh@...nel.org, sdf@...ichev.me,
haoluo@...gle.com, jolsa@...nel.org, horms@...nel.org, bpf@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next v7 11/13] net-timestamp: add a new callback in
tcp_tx_timestamp()
On 1/28/25 12:46 AM, Jason Xing wrote:
> Introduce the callback to correlate tcp_sendmsg timestamp with other
> points, like SND/SW/ACK. We can let bpf trace the beginning of
> tcp_sendmsg_locked() and fetch the socket addr, so that in
Instead of "fetch the socket addr...", should be "store the sendmsg timestamp at
the bpf_sk_storage ...".
> tcp_tx_timestamp() we can correlate the tskey with the socket addr.
> It is accurate since they are under the protect of socket lock.
> More details can be found in the selftest.
The selftest uses the bpf_sk_storage to store the sendmsg timestamp at
fentry/tcp_sendmsg_locked and retrieves it back at tcp_tx_timestamp (i.e.
BPF_SOCK_OPS_TS_SND_CB added in this patch).
>
> Signed-off-by: Jason Xing <kerneljasonxing@...il.com>
> ---
> include/uapi/linux/bpf.h | 7 +++++++
> net/ipv4/tcp.c | 1 +
> tools/include/uapi/linux/bpf.h | 7 +++++++
> 3 files changed, 15 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 800122a8abe5..accb3b314fff 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -7052,6 +7052,13 @@ enum {
> * when SK_BPF_CB_TX_TIMESTAMPING
> * feature is on.
> */
> + BPF_SOCK_OPS_TS_SND_CB, /* Called when every sendmsg syscall
> + * is triggered. For TCP, it stays
> + * in the last send process to
> + * correlate with tcp_sendmsg timestamp
> + * with other timestamping callbacks,
> + * like SND/SW/ACK.
Do you have a chance to look at how this will work at UDP?
Powered by blists - more mailing lists