> On Mar 17, 2020, at 12:54 PM, Song Liu <songliubraving@xxxxxx> wrote: > > > >> On Mar 17, 2020, at 12:30 PM, Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: >> >> On 3/16/20 9:33 PM, Song Liu wrote: >>> 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 <songliubraving@xxxxxx> >> >> Hmm, I see no relation to /dev/bpf_stats anymore, yet the subject still talks >> about it? > > My fault. Will fix.. > >> >> 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
