[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL+tcoBQrEn=qzak0hnX=8=wr1=JKEF+2fSF4TJu08VGTQMN_w@mail.gmail.com>
Date: Tue, 11 Feb 2025 15:31:20 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Martin KaFai Lau <martin.lau@...ux.dev>
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 v9 06/12] bpf: support SCM_TSTAMP_SCHED of SO_TIMESTAMPING
On Tue, Feb 11, 2025 at 3:12 PM Martin KaFai Lau <martin.lau@...ux.dev> wrote:
>
> On 2/8/25 2:32 AM, Jason Xing wrote:
> > Support SCM_TSTAMP_SCHED case. Introduce SKBTX_BPF used as
> > an indicator telling us whether the skb should be traced
> > by the bpf prog.
>
> The BPF side does not exactly support SCM_TSTAMP_SCHED as a report value.
>
> What this patch does is:
>
> Add a new sock_ops callback, BPF_SOCK_OPS_TS_SCHED_OPT_CB. This callback will
> occur at the same timestamping point as the user space's SCM_TSTAMP_SCHED. The
> BPF program can use it to get the same SCM_TSTAMP_SCHED timestamp without
> modifying the user-space application.
>
> A new SKBTX_BPF flag is added to mark skb_shinfo(skb)->tx_flags, ensuring that
> the new BPF timestamping and the current user space's SO_TIMESTAMPING do not
> interfere with each other.
>
> I would remove most of the SO_TIMESTAMPING comments from the commit messages.
> The timestamping points are the same but there is not much overlapping on the
> API side.
>
> Subject could be:
> bpf: Add BPF_SOCK_OPS_TS_SCHED_OPT_CB callback
>
> [ The same probably for patch 7-9. ]
Thanks. I will similarly adjust them as well :)
Thanks,
Jason
Powered by blists - more mailing lists