Re: [RESEND PATCH bpf-next v4 1/2] bpf, sockmap: Introduce tracing capability for sockmap

["Jiayuan Chen" <jiayuan.chen@linux.dev>]

May 7, 2025 at 04:24, "Martin KaFai Lau" <martin.lau@linux.dev> wrote:

> 
> On 5/5/25 7:51 PM, Jiayuan Chen wrote:
> 
> > 
> > Sockmap has the same high-performance forwarding capability as XDP, but
> > 
> >  operates at Layer 7.
> > 
> >  Introduce tracing capability for sockmap, to trace the execution results
> > 
> >  of BPF programs without modifying the programs themselves, similar to
> > 
> >  the existing trace_xdp_redirect{_map}.
> > 
> 
> There were advancements in bpf tracing since the trace_xdp_xxx additions.
> 
> Have you considered the fexit bpf prog and why it is not sufficient ?
> 

1.This patchset prints a large amount of information (e.g. inode ID, etc.),
some of which require kernel-internal helpers to access. These helpers are
not currently available as kfuncs, making it difficult to implement
equivalent functionality with fentry/fexit.

2. skb->_sk_redir implicitly stores both a redir action and the socket address
in a single field. Decoding this structure in fentry/fexit would require
duplicating kernel-internal logic in BPF programs. This creates maintenance
risks, as any future changes to the kernel's internal representation would
necessitate corresponding updates to the BPF programs.

3. Similar to the debate between using built-in tracepoints vs kprobes/fentry,
each approach has its tradeoffs. The key advantage of a built-in tracepoint is
seamless integration with existing tools like perf and bpftrace, which natively
support tracepoint-based tracing. For example, simply executing
'perf trace -e 'sockmap:*' ./producer' could provide sufficient visibility
without custom BPF programs.