On Wed, Mar 18, 2026 at 9:40 AM Vineeth Remanan Pillai <[email protected]> wrote: > > On Thu, Mar 12, 2026 at 11:31 AM Aaron Conole <[email protected]> wrote: > > > > "Vineeth Pillai (Google)" <[email protected]> writes: > > > > > Replace trace_foo() with the new trace_invoke_foo() at sites already > > > guarded by trace_foo_enabled(), avoiding a redundant > > > static_branch_unlikely() re-evaluation inside the tracepoint. > > > trace_invoke_foo() calls the tracepoint callbacks directly without > > > utilizing the static branch again. > > > > > > Suggested-by: Steven Rostedt <[email protected]> > > > Suggested-by: Peter Zijlstra <[email protected]> > > > Signed-off-by: Vineeth Pillai (Google) <[email protected]> > > > Assisted-by: Claude:claude-sonnet-4-6 > > > --- > > > net/core/dev.c | 2 +- > > > net/core/xdp.c | 2 +- > > > net/openvswitch/actions.c | 2 +- > > > net/openvswitch/datapath.c | 2 +- > > > net/sctp/outqueue.c | 2 +- > > > net/tipc/node.c | 2 +- > > > 6 files changed, 6 insertions(+), 6 deletions(-) > > > > > > diff --git a/net/core/dev.c b/net/core/dev.c > > > index 14a83f2035b93..a48fae2bbf57e 100644 > > > --- a/net/core/dev.c > > > +++ b/net/core/dev.c > > > @@ -6444,7 +6444,7 @@ void netif_receive_skb_list(struct list_head *head) > > > return; > > > if (trace_netif_receive_skb_list_entry_enabled()) { > > > list_for_each_entry(skb, head, list) > > > - trace_netif_receive_skb_list_entry(skb); > > > + trace_invoke_netif_receive_skb_list_entry(skb); > > > } > > > netif_receive_skb_list_internal(head); > > > trace_netif_receive_skb_list_exit(0); > > > diff --git a/net/core/xdp.c b/net/core/xdp.c > > > index 9890a30584ba7..53acc887c3434 100644 > > > --- a/net/core/xdp.c > > > +++ b/net/core/xdp.c > > > @@ -362,7 +362,7 @@ int xdp_rxq_info_reg_mem_model(struct xdp_rxq_info > > > *xdp_rxq, > > > xsk_pool_set_rxq_info(allocator, xdp_rxq); > > > > > > if (trace_mem_connect_enabled() && xdp_alloc) > > > - trace_mem_connect(xdp_alloc, xdp_rxq); > > > + trace_invoke_mem_connect(xdp_alloc, xdp_rxq); > > > return 0; > > > } > > > > > > diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c > > > index 792ca44a461da..420eb19322e85 100644 > > > --- a/net/openvswitch/actions.c > > > +++ b/net/openvswitch/actions.c > > > @@ -1259,7 +1259,7 @@ static int do_execute_actions(struct datapath *dp, > > > struct sk_buff *skb, > > > int err = 0; > > > > > > if (trace_ovs_do_execute_action_enabled()) > > > - trace_ovs_do_execute_action(dp, skb, key, a, rem); > > > + trace_invoke_ovs_do_execute_action(dp, skb, key, a, > > > rem); > > > > Maybe we should just remove the guard here instead of calling the > > invoke. That seems better to me. It wouldn't need to belong to this > > series. > > > > > /* Actions that rightfully have to consume the skb should > > > do it > > > * and return directly. > > > diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c > > > index e209099218b41..02451629e888e 100644 > > > --- a/net/openvswitch/datapath.c > > > +++ b/net/openvswitch/datapath.c > > > @@ -335,7 +335,7 @@ int ovs_dp_upcall(struct datapath *dp, struct sk_buff > > > *skb, > > > int err; > > > > > > if (trace_ovs_dp_upcall_enabled()) > > > - trace_ovs_dp_upcall(dp, skb, key, upcall_info); > > > + trace_invoke_ovs_dp_upcall(dp, skb, key, upcall_info); > > > > Same as above. Seems OVS tracepoints are the only ones that include > > the guard without any real reason. > > > > Makes sense. Its simple enough that I think I will include it as a > separate patch in v2 and remove these changes from this patch. Thanks > for pointing it out. > On a second look, I'm not sure if this was for performance reasons. The discussion in the io_uring patch in this series points out that the check made there was deliberate and for performance reasons to avoid 6 mov instruction in the hot path. Just wanted to double check if that was the case here, before I remove the check?
Thanks, Vineeth _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
