Re: [PATCH v3 bpf-next 03/11] bpf: tcp: Support bpf_skb_load_bytes() for BPF_SOCK_OPS_RCVQ_CB.

[Martin KaFai Lau <martin.lau@linux.dev>]

On Wed, May 27, 2026 at 12:46:25PM -0700, Martin KaFai Lau wrote:
> > > > > If this new rcvq callback is added to the 'bpf_tcp_ops' proposal [1],
> > > > > all this will go away. 'struct sk_buff *skb' can be directly passed to an
> > > > > ops of the 'bpf_tcp_ops'. Supporting '*skb' in a struct_ops has already
> > > > > been done in the bpf_qdisc.
> > > > >
> > > > > [1]: https://lore.kernel.org/bpf/20260519215841.2984970-11-martin.lau@linux.dev/
> > > >
> > > > Oh I missed the series, the struct_ops conversion looks nice !
> > > > Since this work isn't urgent, I can wait for your series if mine
> > > > churns it.
> > > >
> > > > Jason's series is adding a new op, and I guess this can be
> > > > integrated too ?
> > > > https://lore.kernel.org/bpf/20260521135244.40869-5-kerneljasonxing@gmail.com/
> > >
> > > imo, a new sock_ops cb should be added as an ops in struct_ops. For example,
> > > in patch 4 of that series, bpf_skops_rx_timestamping assigns u64 to 'u32
> > > args[4]', which is adding tech debt to the current sock_ops interface.
> > > For the timestamping case, it could be a separate ops for the
> > > 'struct sock' instead of 'struct tcp_sock' because it should
> > > at least work for both TCP and UDP.
> > 
> > Sorry, I don't get it. What is the tech debt in this? And
> > bpf_skops_rx_timestamping() only outputs the timestamps, which has
> > nothing to do with either 'sock' or 'tcp_sock'.
> 
> Did I say the tech debt is in bpf_skops_rx_timestamping?
> I said the tech debt of the bpf_sock_ops[_kern] interface.
> Besides always memzero the whole &sockops, the way that the bpf prog
> needs to get a u64 timestamp from u32 is not thrilling in 2026.
> args[4] is also not reliable when the earlier cgroup bpf prog
> writes to replylong. We had already hit some of these in our rx net
> timestamping discussion a few years ago. I suggest you go back
> and revisit.
> 
> > 
> > Could you show me what to do next? Thanks in advance. It sounds like
> > the tx side of bpf timestamping should be adjusted accordingly?
> 
> imo, the bpf_tcp_ops can land first. and then add net timestamping
> ops (existing tx and the new rx) in bpf_sock_ops.
To be clear, for bpf_sock_ops, I meant a struct_ops named bpf_sock_ops (or
another better name).