Re: [PATCH net-next 5/6] bpf: enable bpf timestamping rx in TCP layer

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Jason Xing <kerneljasonxing@gmail.com> writes:

> On Tue, May 19, 2026 at 7:16 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
>>
>> On Tue, May 19, 2026 at 12:40 AM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
>> >
>> >
>> >
>> > On 18/05/2026 15.53, Jason Xing wrote:
>> > > On Mon, May 18, 2026 at 9:01 PM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
>> > >>
>> > >>
>> > >>
>> > >> On 18/05/2026 10.23, Jason Xing wrote:
>> > >>> From: Jason Xing <kernelxing@tencent.com>
>> > >>>
>> > >>> Add two if statements to accurately isolate bpf timestamping and so
>> > >>> timestamping. They can work respectively.
>> > >>>
>> > >>> As to so_timestamping, only add a loose condition via report flags
>> > >>> to avoid duplicate strict checks that is done in tcp_recv_timestamp()
>> > >>> and performance impact. If the loose condition is hit,
>> > >>> tcp_recv_timestamp() is able to handle the exact case and doesn't
>> > >>> hamper the existing timestamping feature.
>> > >>>
>> > >>> Make it work in TCP protocol.
>> > >>>
>> > >>> Signed-off-by: Jason Xing <kernelxing@tencent.com>
>> > >>> ---
>> > >>>    net/ipv4/tcp.c | 14 ++++++++++++--
>> > >>>    1 file changed, 12 insertions(+), 2 deletions(-)
>> > >>>
>> > >>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>> > >>> index 21ece4c71612..64c69bb3578a 100644
>> > >>> --- a/net/ipv4/tcp.c
>> > >>> +++ b/net/ipv4/tcp.c
>> > >>> @@ -2949,8 +2949,18 @@ int tcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int flags)
>> > >>>        release_sock(sk);
>> > >>>
>> > >>>        if ((cmsg_flags | msg->msg_get_inq) && ret >= 0) {
>> > >>> -             if (cmsg_flags & TCP_CMSG_TS)
>> > >>> -                     tcp_recv_timestamp(msg, sk, &tss);
>> > >>> +             if (cmsg_flags & TCP_CMSG_TS) {
>> > >>> +                     u32 tsflags = READ_ONCE(sk->sk_tsflags);
>> > >>> +
>> > >>> +                     if (cgroup_bpf_enabled(CGROUP_SOCK_OPS) &&
>> > >>> +                         SK_BPF_CB_FLAG_TEST(sk, SK_BPF_CB_RX_TIMESTAMPING))
>> > >>> +                             bpf_skops_rx_timestamping(sk, &tss,
>> > >>> +                                                       BPF_SOCK_OPS_TSTAMP_RCV_CB);
>> > >>
>> > >> Does this mean I can enable timestamp reading per cgroup?
>> > >
>> > > Yes, I think so, but I didn't try. One of the natures of sockopt
>> > > feature is supporting cgroup attach.
>> > > cgroup_bpf_prog_attach()/cgroup_bpf_link_attach() is probably
>> > > something that you're looking for.
>> > >
>> >
>> > Sound good
>> >
>> > > IIUC, you can attach the prog onto the cgroup where all the sockets
>> > > are set using the bpf timestamping function. So the current impl is
>> > > cleaner and has better isolation (to filter out those unmatched
>> > > flows).
>> > >
>> > >>
>> > >> In Simon's netstacklat[1] tool we are forced process all RX timestamp
>> > >> (hooking fentry/tcp_recv_timestamp), and then we have a BPF filter[2] on
>> > >> the cgroup IDs that we are interested in (which is a significant
>> > >> overhead, as this is deployed at Cloudflare production scale).
>> > >
>> > > I can feel the pain when filtering in this kind of relatively hot
>> > > path, which is what I'm trying to avoid internally. What I've done in
>> > > production (to cover those old kernels) is to just let the kernel
>> > > print the information, that's it, and there is an agent continuously
>> > > gathering the data, doing the match and computing latency. But it's
>> > > overall complicated.
>> > >
>> >
>> > I hope you don't mean your internal/old approach was using printk and
>> > then analyzing this data.
>>
>> Of course not :)
>>
>> The internal approach is to cover the old kernels but doesn't mean the
>> approach is old :P
>>
>> Instead, the internal kernel module is super efficient and I'm trying
>> to ship bpf with such an ability. The fact is we've already deployed
>> in production: 7x24 running, zero sampling.
>>
>> Please see page 24 where there is a brief introduction on how to deal
>> with the log part:
>> https://lpc.events/event/19/contributions/2055/#preview:3846
>> I believe this is the promising direction (ring buffer + lightweight
>> kernel + heavy agent) we're taking.
>>
>> The headache part is that I need to provide an agent written in BPF to
>> do the heavy process.
>>
>> >
>> > > Many thanks here, I'm always interested in hearing more useful and
>> > > real requirements and fancy ideas on how to monitor the latency :) Now
>> >
>> > Simon Sundberg <Simon.Sundberg@kau.se> have many more fancy ideas on how
>> > to monitor the latency.
>> > The netstacklat tool is part of Simon's PhD thesis:
>> > - https://doi.org/10.59217/qklv6836
>> >
>> > And we even gotten a paper accepted on netstacklat:
>> > -
>> > https://kau.diva-portal.org/smash/record.jsf?pid=diva2%3A2034009&dswid=3032
>>
>> Sorry, I cannot access this link. Could you give me the title of this paper?
>
> Waiting at the Front Door - Continuous Monitoring of Latency in the
> Host Network Stack
>
> Oh, I guess it hasn't been officially published right? This is the
> reason why I have no way to know the content.

No, it's not published yet; I'll send you a copy off-list :)

-Toke