From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jason Xing <kerneljasonxing@gmail.com>,
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
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
Jason Xing <kernelxing@tencent.com>
Subject: Re: [PATCH net-next 0/9] net-timestamp: bpf extension to equip applications transparently
Date: Tue, 08 Oct 2024 14:44:25 -0400 [thread overview]
Message-ID: <67057d89796b_1a41992944c@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <20241008095109.99918-1-kerneljasonxing@gmail.com>
Jason Xing wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> A few weeks ago, I planned to extend SO_TIMESTMAMPING feature by using
> tracepoint to print information (say, tstamp) so that we can
> transparently equip applications with this feature and require no
> modification in user side.
>
> Later, we discussed at netconf and agreed that we can use bpf for better
> extension, which is mainly suggested by John Fastabend and Willem de
> Bruijn. Many thanks here! So I post this series to see if we have a
> better solution to extend.
>
> This approach relies on existing SO_TIMESTAMPING feature, for tx path,
> users only needs to pass certain flags through bpf program to make sure
> the last skb from each sendmsg() has timestamp related controlled flag.
> For rx path, we have to use bpf_setsockopt() to set the sk->sk_tsflags
> and wait for the moment when recvmsg() is called.
As you mention, overall I am very supportive of having a way to add
timestamping by adminstrators, without having to rebuild applications.
BPF hooks seem to be the right place for this.
There is existing kprobe/kretprobe/kfunc support. Supporting
SO_TIMESTAMPING directly may be useful due to its targeted feature
set, and correlation between measurements for the same data in the
stream.
> After this series, we could step by step implement more advanced
> functions/flags already in SO_TIMESTAMPING feature for bpf extension.
My main implementation concern is where this API overlaps with the
existing user API, and how they might conflict. A few questions in the
patches.
Also, I'm not the best person to give in-depth BPF feedback.
> Here is the test output:
> 1) receive path
> iperf3-987305 [008] ...11 179955.200990: bpf_trace_printk: rx: port: 5201:55192, swtimestamp: 1728167973,670426346, hwtimestamp: 0,0
> 2) xmit path
> iperf3-19765 [013] ...11 2021.329602: bpf_trace_printk: tx: port: 47528:5201, key: 1036, timestamp: 1728357067,436678584
> iperf3-19765 [013] b..11 2021.329611: bpf_trace_printk: tx: port: 47528:5201, key: 1036, timestamp: 1728357067,436689976
> iperf3-19765 [013] ...11 2021.329622: bpf_trace_printk: tx: port: 47528:5201, key: 1036, timestamp: 1728357067,436700739
next prev parent reply other threads:[~2024-10-08 18:44 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 9:51 [PATCH net-next 0/9] net-timestamp: bpf extension to equip applications transparently Jason Xing
2024-10-08 9:51 ` [PATCH net-next 1/9] net-timestamp: add bpf infrastructure to allow exposing more information later Jason Xing
2024-10-08 18:45 ` Willem de Bruijn
2024-10-08 23:27 ` Jason Xing
2024-10-09 13:22 ` Willem de Bruijn
2024-10-09 13:57 ` Jason Xing
2024-10-09 0:58 ` Kuniyuki Iwashima
2024-10-09 8:11 ` Jason Xing
2024-10-08 9:51 ` [PATCH net-next 2/9] net-timestamp: introduce TS_SCHED_OPT_CB to generate dev xmit timestamp Jason Xing
2024-10-08 9:51 ` [PATCH net-next 3/9] net-timestamp: introduce TS_SW_OPT_CB to generate driver timestamp Jason Xing
2024-10-08 19:13 ` Vadim Fedorenko
2024-10-08 23:08 ` Jason Xing
2024-10-08 9:51 ` [PATCH net-next 4/9] net-timestamp: introduce TS_ACK_OPT_CB to generate tcp acked timestamp Jason Xing
2024-10-08 9:51 ` [PATCH net-next 5/9] net-timestamp: ready to turn on the button to generate tx timestamps Jason Xing
2024-10-08 18:53 ` Willem de Bruijn
2024-10-08 23:37 ` Jason Xing
2024-10-08 19:18 ` Vadim Fedorenko
2024-10-08 23:48 ` Jason Xing
2024-10-09 9:16 ` Vadim Fedorenko
2024-10-09 11:15 ` Jason Xing
2024-10-08 9:51 ` [PATCH net-next 6/9] net-timestamp: add tx OPT_ID_TCP support for bpf case Jason Xing
2024-10-08 18:56 ` Willem de Bruijn
2024-10-08 23:18 ` Jason Xing
2024-10-09 13:19 ` Willem de Bruijn
2024-10-09 13:52 ` Jason Xing
2024-10-08 9:51 ` [PATCH net-next 7/9] net-timestamp: open gate for bpf_setsockopt Jason Xing
2024-10-09 7:19 ` Martin KaFai Lau
2024-10-09 8:09 ` Jason Xing
2024-10-09 13:23 ` Willem de Bruijn
2024-10-09 13:48 ` Jason Xing
2024-10-08 9:51 ` [PATCH net-next 8/9] net-timestamp: add bpf framework for rx timestamps Jason Xing
2024-10-09 0:22 ` Jakub Kicinski
2024-10-09 0:30 ` Jason Xing
2024-10-09 2:33 ` kernel test robot
2024-10-09 4:17 ` kernel test robot
2024-10-09 5:09 ` kernel test robot
2024-10-08 9:51 ` [PATCH net-next 9/9] net-timestamp: add bpf support for rx software/hardware timestamp Jason Xing
2024-10-08 18:44 ` Willem de Bruijn [this message]
2024-10-08 23:22 ` [PATCH net-next 0/9] net-timestamp: bpf extension to equip applications transparently Jason Xing
2024-10-09 1:05 ` Jason Xing
2024-10-09 9:27 ` Vadim Fedorenko
2024-10-09 11:12 ` Jason Xing
2024-10-09 11:48 ` Jason Xing
2024-10-09 13:16 ` Vadim Fedorenko
2024-10-09 13:47 ` Jason Xing
2024-10-09 13:58 ` Vadim Fedorenko
2024-10-09 14:35 ` Jason Xing
2024-10-09 14:59 ` Vadim Fedorenko
2024-10-09 15:20 ` 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=67057d89796b_1a41992944c@willemb.c.googlers.com.notmuch \
--to=willemdebruijn.kernel@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=kerneljasonxing@gmail.com \
--cc=kernelxing@tencent.com \
--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=song@kernel.org \
--cc=willemb@google.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).