On Sat, Feb 23, 2019 at 02:06:56AM +0100, Daniel Borkmann wrote: > > In general, having some stats and timing info would be useful, but I > guess people might want to customize it in future even more specifically > beyond number of runs + time it takes. One thing that would be super > useful is to have some notion of __attribute__((constructor)) and > __attribute__((destructor)) support in BPF which gets then inlined into > prologue / epilogue of program. E.g. such infrastructure would allow to > mark an skb and measure time it takes through the BPF prog till it hits > an exit point somewhere (without having to explicitly code this into the > program everywhere). Other examples may be histograms or p99 latencies > that might probably be useful. Feels like for monitoring more ways to > program would be nice and to move it into the BPF insns sequence (e.g. > enforced globally or by choice of prog as another option)? Thoughts?
the constructor/destructor you mean to capture the full sequence of tail_calls? Or full path of skb through the stack with all hook points? That is likely very useful without any bpf, but I think hw timestamping already serves that purpose. I've been thinking about doing this stats per program (instead of static_key for all). Like replacing a bpf_prog->bpf_func with a wrapper function that does stats, but that is more costly in retpoline world due to extra indirect call. Another alternative is to patch the stats in via JITs, but it's much more complex and error prone. So went with the simplest approach. With all stats ideas we need to be careful not to reintroduce what perf is already great at. These stats are _not_ for performance analysis. That's what perf does. These stats are for 24/7 monitoring to catch things that not suppose to happen.
