[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL+tcoBGQZWZr3PU4Chn1YiN8XO_2UXGOh3yxbvymvojH3r13g@mail.gmail.com>
Date: Wed, 9 Oct 2024 07:22:26 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, dsahern@...nel.org, willemb@...gle.com, ast@...nel.org,
daniel@...earbox.net, andrii@...nel.org, martin.lau@...ux.dev,
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, bpf@...r.kernel.org,
netdev@...r.kernel.org, Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next 0/9] net-timestamp: bpf extension to equip
applications transparently
On Wed, Oct 9, 2024 at 2:44 AM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> Jason Xing wrote:
> > From: Jason Xing <kernelxing@...cent.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.
Agreed. That's also what I'm concerned about. So I decided to ask for
related experts' help.
How to deal with it without interfering with the existing apps in the
right way is the key problem.
Powered by blists - more mailing lists