Re: [PATCH net-next] udp: Add tracepoint for udp_sendmsg()

Breno Leitao
2025-04-17T11:32:00Z

Hello Willem,

On Wed, Apr 16, 2025 at 03:34:38PM -0400, Willem de Bruijn wrote:
> Breno Leitao wrote:
> > Add a lightweight tracepoint to monitor UDP send message operations,
> > similar to the recently introduced tcp_sendmsg_locked() trace event in
> > commit 0f08335ade712 ("trace: tcp: Add tracepoint for
> > tcp_sendmsg_locked()")
> >
> > This implementation uses DECLARE_TRACE instead of TRACE_EVENT to avoid
> > creating extensive trace event infrastructure and exporting to tracefs,
> > keeping it minimal and efficient.
> >
> > Since this patch creates a rawtracepoint, it can be accessed using
> > standard tracing tools like bpftrace:
> >
> > rawtracepoint:udp_sendmsg_tp {
> > ...
> > }
>
> What does this enable beyond kfunc:udp_sendmsg?

A few things come to mind when evaluating the use of tracepoints.

One significant advantage is that tracepoints provide a stable API where
programs can hook into, making it easier for users to interact with key
functions.

However, kfunc/kprobes has some notable disadvantages. For instance,
partial or total inlining can cause hooks to fail, which is not ideal
and can lead to issues (mainly when we have partial inlines, and the
hook works _sometimes_).

In contrast, tracepoints create a more stable API for users to hook
into, eliminating the need to patch the kernel with noinline function
attributes. This solution may be ugly, but it is a common practice.
(and this is my main goal with it, remove `noinline` from our internal
kernel)

While tracepoints are not officially considered stable APIs, they tend
to be "more stable" in practice due to their deliberate and strategic
placement. As a result, they are less likely to get renamed or changed
frequently.

Additionally, tracepoints offer performance benefits, being faster than
both kfunc and kprobes.

For further discussion on this topic, please refer to same discussion in
VFS:

https://lore.kernel.org/bpf/20250118033723.GV1977892@ZenIV/T/#m4c2fb2d904e839b34800daf8578dff0b9abd69a0

Thanks
--breno