Re: [PATCH net-next] udp: Add tracepoints to monitor skbs going in and out of a UDP socket

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Fri, Oct 05, 2018 at 12:24:42AM +0100, David Howells wrote:
> 
> As for kprobes: spots, plural.  Using kprobes involves installing breakpoint
> instructions and taking traps and would seem to require using printk for the
> output, which would affect the timings and potentially affect the situation,
> especially given the sheer amount of traces produced.  Note that one of these
> was in an interrupt handler, which is possibly not the best place to be taking
> an illegal instruction trap.
> 
> Using kprobes gets worse too.  In my case, the source code and the build tree
> aren't on the test machine, which I understand would be a requirement - and

there is quite a bit of misunderstanding in the above two paragraphs about kprobes.
Sounds like it influences odd design choices with tracepoints.

- kprobes at the top of the function don't use traps and they've been
optimized over the years to have very low overhead
- trace_printk is using the same mechanism as tracepoint prints
- both trace_printk and tracepoints can affect timing
- kprobes and trace_printk work well out of irq handler. They work out of NMI too
- build tree doesn't need to be present to use kprobes

perf, bcc and others tools have user friendly (arguable of course) interfaces
for kprobes.