[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181219115524.0b9f9f3f@gandalf.local.home>
Date: Wed, 19 Dec 2018 11:55:24 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Jesper Dangaard Brouer <brouer@...hat.com>
Cc: Daniel Borkmann <borkmann@...earbox.net>,
Stephen Hemminger <stephen@...workplumber.org>,
netdev@...r.kernel.org, Stephen Hemminger <sthemmin@...rosoft.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH net-next] net: add network device notifier trace points
On Wed, 19 Dec 2018 17:40:49 +0100
Jesper Dangaard Brouer <brouer@...hat.com> 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
Powered by blists - more mailing lists