[...]
>
>> +int
>> +rte_pmu_init(void)
>> +{
>> + int ret;
>> +
>> + /* Allow calling init from multiple contexts within a single
>> thread. This simplifies
>> + * resource management a bit e.g in case fast-path tracepoint has
>> already been enabled
>> + * via command line but application doesn't care enough and
>> performs init/fini again.
>> + */
>> + if (rte_pmu.initialized != 0) {
>> + rte_pmu.initialized++;
>
>This increment is not multithread safe, does it need to be?
>
This was introduced *solely* to allow running fast-test (pmu_autotest) along
with trace_perf_autotest. The thing is if you execute dpdk-test and have fast
tracepoint option enabled then EAL will initialize pmu by itself. OTOH
pmu_autotest is more for testing API calls than anything else so it initializes
pmu too.
In order to avoid this situation where pmu gets initialized twice we have that
counter.
If someone calls this API concurrently then we indeed face synchronization
issues as you rightfully pointed out. I don't know to what extent calling
init/fini from different context proves useful but I can harden this part just
in case. Thanks for pointing this context out.
>Same about the decrement in rte_pmu_fini().
>
>> + return 0;
>> + }
>
>With the above fixed, or if it doesn't need fixing,
>
>For the series,
>Acked-by: Morten Brørup <m...@smartsharesystems.com>
>
>Thank you for resuming work on this. :-)
