Re: [PATCH v2 bpf-next/net 0/5] bpf: Support RX/TX HW timestamp proxy.

[Jakub Kicinski <kuba@kernel.org>]

On Sat, 13 Jun 2026 14:43:46 -0700 Kuniyuki Iwashima wrote:
> On Sat, Jun 13, 2026 at 10:20 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > On Sat, 13 Jun 2026 00:59:57 +0000 Kuniyuki Iwashima wrote:  
> > > When standard socket applications are run on these hosts,
> > > a userspace proxy is required to mediate traffic between the
> > > hardware and the applications.
> > >
> > >             +---------+                 +----------------------+
> > >             |  proxy  |                 |  socket application  |
> > >             +---------+                 +----------------------+
> > >               ^     ^                               ^
> > >   userspace   |     |                               |
> > >   -----------| |-----------------------------------------------
> > >              | |    |    +---------------------+    | skb
> > >              | |    `--->|  virtual interface  |<---'
> > >   kernel     | |   skb   +---------------------+
> > >   -----------| |-----------------------------------------------
> > >               |
> > >               v
> > >        +------------+
> > >        |  hardware  |
> > >        +------------+  
> >
> > The first patch looks kinda nonsensical but then I saw this diagram.
> > Looks like you're vibe coding an integration that makes it easier to
> > treat netdev as a slow path for a user networking stack.
> > Please tell me if I'm missing anything otherwise add my nack if you
> > repost.  
> 
> Hmm, what would be a better way to tell users that HW TS is
> available on tunnel devices ?
> 
> Other options were 1) add attribute to tie the tunnel to a physical
> device and use its ndo_hwtstamp_set/get, or 2) add bpf retval
> hook in the path like update_socket_protocol().

Can you explain the use case for HW timestamps on tunnels?
I see you have some diagrams in patches 3 and 4 but the motivation
isn't really explained, and we have 250 patches in the queue still.
Not much time to play detective right now :/

> Or do you think applications should handle ENOTSUP by ioctl
> as soft error and always set SOF_TIMESTAMPING_XXX_HARDWARE
> since the underlying physical device may support it ?

And explain the deployment model and API semantics you have in mind.

> Anyway, I'm happy to drop patch 1 for now and explore options.

Not patch 1, all of it. I get the feeling y'all are sitting on a pile
of Swift related code that needs to be made upstreamable. Odd series
like this make me think it's never going to happen.

> (Believe it or not, I haven't let AI write code because I don't
>  want AI to take over the most fun part.)