[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250418083351.20a60e64@gandalf.local.home>
Date: Fri, 18 Apr 2025 08:33:51 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: David Ahern <dsahern@...nel.org>
Cc: Breno Leitao <leitao@...ian.org>, Willem de Bruijn
<willemdebruijn.kernel@...il.com>, Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
<horms@...nel.org>, kuniyu@...zon.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
yonghong.song@...ux.dev, song@...nel.org, kernel-team@...a.com
Subject: Re: [PATCH net-next] udp: Add tracepoint for udp_sendmsg()
On Thu, 17 Apr 2025 21:57:56 -0700
David Ahern <dsahern@...nel.org> wrote:
> On 4/17/25 10:00 AM, Breno Leitao wrote:
> >> $ git grep trace_ net drivers/net | grep _tp
> >> net/bpf/test_run.c: trace_bpf_trigger_tp(nonce);
> >> net/ipv4/tcp_input.c: trace_tcp_cwnd_reduction_tp(sk,
> >> newly_acked_sacked, newly_lost, flag);
> >
> > Do we want to rename them and remove the _tp? I suppose it is OK given
> > that tracepoints are not expected to be stable?
> >
> > Also, if we have consensus about this patch, I will remove the _tp from
> > it.
> >
>
> I am only asking for consistency. Based on existing networking
> instances, consistency is no _tp suffix.
I was looking at what other tracepoints have "_tp" and found a few. What it
appears to be is that the "_tp" tracepoints are defined by:
DECLARE_TRACEPOINT()
and have no corresponding trace event in tracefs (/sys/kernel/tracing/events).
I like that distinction because it lets the developer know that this
tracepoint is in kernel only, and not exposed to user space.
Perhaps it should stay as "_tp()" if it's not exposed via tracefs.
In fact, if there is a clean up, it should be adding "_tp" to all
tracepoints that do not have a corresponding trace event attached to them.
As they are in kernel only, that change should not cause any ABI breakage.
-- Steve
Powered by blists - more mailing lists