All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Jason Xing" <kerneljasonxing@gmail.com>, <davem@davemloft.net>,
	<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
	<horms@kernel.org>, <willemb@google.com>, <kuniyu@google.com>
Cc: <netdev@vger.kernel.org>, <bpf@vger.kernel.org>,
	"Jason Xing" <kernelxing@gmail.com>
Subject: Re: [PATCH RFC net-next 0/9] net: BPF Timestamping 2.0 for TCP
Date: Sat, 19 Sep 2026 18:12:17 +0000	[thread overview]
Message-ID: <DLJHVEYXMZ6R.1YX59HGMRMYO0@gmail.com> (raw)
In-Reply-To: <20260919143732.11772-1-kerneljasonxing@gmail.com>

On Sat Sep 19, 2026 at 2:37 PM UTC, Jason Xing wrote:
> From: Jason Xing <kernelxing@gmail.com>
>
> Greeting,
>
> It's BPF Timestamping 2.0 that aims to observe the packet latency
> more efficiently and simply for different protocols. The current
> series is only focused on TCP protocol.
>
> At Netdev 0x1a/Netconf 2026, the history, background, motivation and
> rough implementation of the feature were exhaustively introduced[1].
>
> History
> =======
> - In 2009, Patrick Ohly implemented the basic infrastructure
> - In 2014, Willem de Bruijn enhanced the TCP latency observation
> - In 2024, Jason Xing proposed its lightweight BPF version
> Detailed slides from 28 to 32 [1].
>
> Background
> ==========
> Even though BPF Timetamping 1.0 is comparatively low-overhead,
> transparent, it's still complicated due to a few points inherited
> from the design:
> - Inflexible/fixed reporting phases (qdisc/driver/ack)
>   When we confirm the issue arises from the kernel by using attribution
>   ability of timestamping feature, we need to further minimize the scope
>   until the issue is fixed. That means, we then have to resort to write
>   a few complex BPF progs with the similar functionalities (like skb
>   level tag) which should not happen.
> - Not enough low-overhead
>   Serving the sensitive applications, an always-on latency observation
>   platform should mitigate the self-impact as much as possible. As we
>   can conclude from BPF Timestamping selftests, there are some blocking
>   and time-consuming points like where reading/writing BPF maps happen
>   in the extremely hot paths.
> - Minor flaws
>   There are a few minor flaws inherited from the initial design, like
>   missing tagging the last packet[2][3][4].


All these "issues" sound minor and on their own do not warrant new uapi.

This RFC don't even have an example of how it could be used end-to-end.

So soft nack from me for now.

pw-bot: cr

  parent reply	other threads:[~2026-09-19 18:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-19 14:37 [PATCH RFC net-next 0/9] net: BPF Timestamping 2.0 for TCP Jason Xing
2026-09-19 14:37 ` [PATCH RFC net-next 1/9] net: add bpf_setsockopt for SK_BPF_CB_TIMESTAMPING_V2 Jason Xing
2026-09-20 14:39   ` sashiko-bot
2026-09-19 14:37 ` [PATCH RFC net-next 2/9] bpf: add bpf_ktime_get_real_ns() kfunc Jason Xing
2026-09-20 14:39   ` sashiko-bot
2026-09-19 14:37 ` [PATCH RFC net-next 3/9] tcp: record a start time in the tx path for SK_BPF_CB_TIMESTAMPING_V2 Jason Xing
2026-09-20 14:39   ` sashiko-bot
2026-09-19 14:37 ` [PATCH RFC net-next 4/9] net: reuse skb_shared_hwtstamps for BPF Timestamping v2 Jason Xing
2026-09-20 14:39   ` sashiko-bot
2026-09-19 14:37 ` [PATCH RFC net-next 5/9] net-timestamp: use pskb_copy to avoid polluting the orig skb's start time Jason Xing
2026-09-20 14:39   ` sashiko-bot
2026-09-19 14:37 ` [PATCH RFC net-next 6/9] bpf-timestamping: restore skb hwtstamp if it is used by " Jason Xing
2026-09-20 14:39   ` sashiko-bot
2026-09-19 14:37 ` [PATCH RFC net-next 7/9] tcp: propagate the start time onto every skb in the tx path Jason Xing
2026-09-20 14:39   ` sashiko-bot
2026-09-19 14:37 ` [PATCH RFC net-next 8/9] net: generate the start time for every skb in the rx path Jason Xing
2026-09-20 14:39   ` sashiko-bot
2026-09-19 14:37 ` [PATCH RFC net-next 9/9] tcp: handle the start time of each split skb in the tx path Jason Xing
2026-09-20 14:39   ` sashiko-bot
2026-09-19 18:12 ` Alexei Starovoitov [this message]
2026-09-20  0:41   ` [PATCH RFC net-next 0/9] net: BPF Timestamping 2.0 for TCP Jason Xing
2026-09-21 18:45 ` Stanislav Fomichev
2026-09-22  1:20   ` Jason Xing
2026-09-22 20:53     ` Stanislav Fomichev
2026-09-23  9:40       ` Jason Xing
2026-09-24 16:11         ` Stanislav Fomichev
2026-09-30 10:21           ` 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=DLJHVEYXMZ6R.1YX59HGMRMYO0@gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kerneljasonxing@gmail.com \
    --cc=kernelxing@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.