include/trace/events/xdp.h | 2 ++ 1 file changed, 2 insertions(+)
From: Steven Rostedt <rostedt@goodmis.org>
The events xdp_cpumap_kthread, xdp_cpumap_enqueue and xdp_devmap_xmit are
only called when CONFIG_BPF_SYSCALL is defined. As each event can take up
to 5K regardless if they are used or not, it's best not to define them
when they are not used. Add #ifdef around these events when they are not
used.
Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
Changes since v1: https://lore.kernel.org/20250612101612.3d4509cc@batman.local.home
- Rebased on top of bpf-next
include/trace/events/xdp.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index d3ef86c97ae3..746a9e95a52a 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -187,6 +187,7 @@ DEFINE_EVENT(xdp_redirect_template, xdp_redirect_map_err,
TP_ARGS(dev, xdp, tgt, err, map_type, map_id, index)
);
+#ifdef CONFIG_BPF_SYSCALL
TRACE_EVENT(xdp_cpumap_kthread,
TP_PROTO(int map_id, unsigned int processed, unsigned int drops,
@@ -300,6 +301,7 @@ TRACE_EVENT(xdp_devmap_xmit,
__entry->sent, __entry->drops,
__entry->err)
);
+#endif /* CONFIG_BPF_SYSCALL */
/* Expect users already include <net/xdp.h>, but not xdp_priv.h */
#include <net/xdp_priv.h>
--
2.47.2
Steven Rostedt <rostedt@goodmis.org> writes: > From: Steven Rostedt <rostedt@goodmis.org> > > The events xdp_cpumap_kthread, xdp_cpumap_enqueue and xdp_devmap_xmit are > only called when CONFIG_BPF_SYSCALL is defined. As each event can take up > to 5K regardless if they are used or not, it's best not to define them > when they are not used. Add #ifdef around these events when they are not > used. > > Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Reviewed-by: Toke Høiland-Jørgensen <toke@kernel.org>
On Thu, Jun 12, 2025 at 3:20 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > From: Steven Rostedt <rostedt@goodmis.org> > > The events xdp_cpumap_kthread, xdp_cpumap_enqueue and xdp_devmap_xmit are > only called when CONFIG_BPF_SYSCALL is defined. As each event can take up > to 5K regardless if they are used or not, it's best not to define them > when they are not used. Add #ifdef around these events when they are not > used. > > Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> > --- > Changes since v1: https://lore.kernel.org/20250612101612.3d4509cc@batman.local.home > > - Rebased on top of bpf-next We can certainly take it, but you mentioned you're working on some patches that will warn when tracepoint is not used. So do you need this to land sooner than the next merge window ?
On Thu, 12 Jun 2025 19:16:33 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > On Thu, Jun 12, 2025 at 3:20 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > > > From: Steven Rostedt <rostedt@goodmis.org> > > > > The events xdp_cpumap_kthread, xdp_cpumap_enqueue and xdp_devmap_xmit are > > only called when CONFIG_BPF_SYSCALL is defined. As each event can take up > > to 5K regardless if they are used or not, it's best not to define them > > when they are not used. Add #ifdef around these events when they are not > > used. > > > > Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> > > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> > > --- > > Changes since v1: https://lore.kernel.org/20250612101612.3d4509cc@batman.local.home > > > > - Rebased on top of bpf-next > > We can certainly take it, but you mentioned you're working > on some patches that will warn when tracepoint is not used. > So do you need this to land sooner than the next merge window ? No. I plan on sending that code near the end of the next merge window to let these patches get in before they start to add warnings. I'm also going to wait till near the end of this cycle before I add that code to linux-next to keep the warnings happening there too soon. So, please take it. That way there's less likelihood of another conflict. Thanks, -- Steve
On Thu, Jun 12, 2025 at 7:27 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Thu, 12 Jun 2025 19:16:33 -0700 > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > > On Thu, Jun 12, 2025 at 3:20 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > > > > > From: Steven Rostedt <rostedt@goodmis.org> > > > > > > The events xdp_cpumap_kthread, xdp_cpumap_enqueue and xdp_devmap_xmit are > > > only called when CONFIG_BPF_SYSCALL is defined. As each event can take up > > > to 5K regardless if they are used or not, it's best not to define them > > > when they are not used. Add #ifdef around these events when they are not > > > used. > > > > > > Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> > > > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> > > > --- > > > Changes since v1: https://lore.kernel.org/20250612101612.3d4509cc@batman.local.home > > > > > > - Rebased on top of bpf-next > > > > We can certainly take it, but you mentioned you're working > > on some patches that will warn when tracepoint is not used. > > So do you need this to land sooner than the next merge window ? > > No. I plan on sending that code near the end of the next merge window > to let these patches get in before they start to add warnings. > > I'm also going to wait till near the end of this cycle before I add > that code to linux-next to keep the warnings happening there too soon. > > So, please take it. That way there's less likelihood of another > conflict. It was applied to bpf-next/net yesterday. pw-bot didn't notice.
On Thu, 12 Jun 2025 22:26:52 -0400 Steven Rostedt <rostedt@goodmis.org> wrote: > > > We can certainly take it, but you mentioned you're working > > on some patches that will warn when tracepoint is not used. > > So do you need this to land sooner than the next merge window ? > BTW, if you are curious about those patches, I just posted them: https://lore.kernel.org/linux-trace-kernel/20250612235827.011358765@goodmis.org/ -- Steve
© 2016 - 2025 Red Hat, Inc.