>> +Performance counter based profiling >> +----------------------------------- >> + >> +Majority of architectures support some performance monitoring unit >(PMU). >> +Such unit provides programmable counters that monitor specific events. > >Sentence wording is awkward, maybe combine the two sentences and/or look >to wikipedia or vendor for better definition. > >Also add PMU to glossary in programmer's guide >
Okay. I'll address that in the next revision. >> + >> +Different tools gather that information, like for example perf. >> +However, in some scenarios when CPU cores are isolated and run >> +dedicated tasks interrupting those tasks with perf may be undesirable. >> + >> +In such cases, an application can use the PMU library to read such events >> via >``rte_pmu_read()``. >> + >> +By default, userspace applications are not allowed to access PMU >> +internals. That can be changed by setting >> +``/sys/kernel/perf_event_paranoid`` to 2 (that should be a default >> +value anyway) and > >Wrong path, should be /proc/sys/kernel/perf_event_paranoid Thanks for catching this. >The default in current kernels is 2. > Right, that's what I meant. Though distros can set paranoia levels to higher values. >> +adding ``CAP_PERFMON`` capability to DPDK application. Please refer >> +to ``Documentation/admin-guide/perf-security.rst`` under Linux >> +sources for more information. Fairly recent kernel, i.e >= 5.9, is advised >> too. > >Provide link to kernel.org page for that doc please. Okay > >Since multiple things (even selinux) can restrict this. Maybe best to just add >a >generic paragraph about what is needed, and leave the security description up >to the kernel and distro to handle. > I'll try to improve that in next release. >> + >> +As of now implementation imposes certain limitations: >> + >> +* Only EAL lcores are supported >> + >> +* EAL lcores must not share a cpu >> + >> +* Each EAL lcore measures same group of events >> +
