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

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

Toke Høiland-Jørgensen <toke@toke.dk> writes:

> 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 :)

In case anyone else is interested, the paper is now on Arxiv:
https://arxiv.org/abs/2606.02057

-Toke