From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Rostedt Subject: Re: [PATCH net-next] net: add network device notifier trace points Date: Wed, 19 Dec 2018 11:55:24 -0500 Message-ID: <20181219115524.0b9f9f3f@gandalf.local.home> References: <20181219022706.10611-1-sthemmin@microsoft.com> <20181219083643.7f724e59@redhat.com> <20181219174049.36952782@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Daniel Borkmann , Stephen Hemminger , netdev@vger.kernel.org, Stephen Hemminger , Alexei Starovoitov , Arnaldo Carvalho de Melo To: Jesper Dangaard Brouer Return-path: Received: from mail.kernel.org ([198.145.29.99]:37078 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728842AbeLSQz1 (ORCPT ); Wed, 19 Dec 2018 11:55:27 -0500 In-Reply-To: <20181219174049.36952782@redhat.com> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 19 Dec 2018 17:40:49 +0100 Jesper Dangaard Brouer wrote: > My napi_monitor use-case is not a slow-path event, even-though in > optimal cases we should handle 64 packets per tracepoint invocation, > but I'm using this for 100G NICs with >20Mpps. And I mostly use the > tool when something looks wrong and I don't see 64 packet bulks, which > is also why I detect when this gets invoked from idle task or from > ksoftirqd. > Would it be possible to add an interface that just connects to the tracepoint without having to use the trace event itself (the trace event is what shows up in tracefs/events/*/*). That would give you full control of what you want: void my_probe(void *data, const struct netdev_notifier_info *info, unsigned long val) { do_something_with(info->dev->ifindex); } void setup(void) { register_trace_netdev_notifier_entry(my_probe, data); } That allows you to attach a function to the tracepoint and not worry about the overhead of what the trace event gives you. -- Steve