On Mar 17, 2020, at 12:54 PM, Song Liu [off-list ref] wrote:

quoted

On Mar 17, 2020, at 12:30 PM, Daniel Borkmann [off-list ref] wrote:

On 3/16/20 9:33 PM, Song Liu wrote:

quoted

Currently, sysctl kernel.bpf_stats_enabled controls BPF runtime stats.
Typical userspace tools use kernel.bpf_stats_enabled as follows:
 1. Enable kernel.bpf_stats_enabled;
 2. Check program run_time_ns;
 3. Sleep for the monitoring period;
 4. Check program run_time_ns again, calculate the difference;
 5. Disable kernel.bpf_stats_enabled.
The problem with this approach is that only one userspace tool can toggle
this sysctl. If multiple tools toggle the sysctl at the same time, the
measurement may be inaccurate.
To fix this problem while keep backward compatibility, introduce a new
bpf command BPF_ENABLE_RUNTIME_STATS. On success, this command enables
run_time_ns stats and returns a valid fd.
With BPF_ENABLE_RUNTIME_STATS, user space tool would have the following
flow:
 1. Get a fd with BPF_ENABLE_RUNTIME_STATS, and make sure it is valid;
 2. Check program run_time_ns;
 3. Sleep for the monitoring period;
 4. Check program run_time_ns again, calculate the difference;
 5. Close the fd.
Signed-off-by: Song Liu <redacted>

Hmm, I see no relation to /dev/bpf_stats anymore, yet the subject still talks
about it?

My fault. Will fix..

quoted

Also, should this have bpftool integration now that we have `bpftool prog profile`
support? Would be nice to then fetch the related stats via bpf_prog_info, so users
can consume this in an easy way.

We can add "run_time_ns" as a metric to "bpftool prog profile". But the 
mechanism is not the same though. Let me think about this. 

Btw, I plan to add this in separate set. Please let me know if it 
preferable to have them in the same set. 

Thanks,
Song