On 02/23/2019 03:38 AM, Alexei Starovoitov wrote: > 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.
Not through the stack, but was more thinking something like low-overhead kprobes-style extension for a BPF prog where such sequence would be added 'inline' at beginning / exit of BPF prog invocation with normal ctx access and helpers as the native program (e.g. time-stamping plus read/write into mark as one example which kprobes couldn't do). But might go much beyond context of this stats collection. > 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. That's actually an interesting thought, given the original prog->bpf_func is a known address at that time, this could be templated where an inner dummy bpf_func call to the normal BPF prog gets later replaced with the actual prog->bpf_func address to have no indirect call. This would also allow to keep the actual prog->bpf_func entry call-sites small and simple. > 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. Pure BPF insns rewrite via JIT would indeed be unclear wrt per-cpu data structures. > With all stats ideas we need to be careful not to reintroduce what > perf is already great at. Yeah agree. > 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. Thanks, Daniel
