RE: [PATCH v12 1/4] lib: add generic support for reading PMU events

[Tomasz Duszynski <tduszynski@marvell.com>]

[...]
>
>> +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 <mb@smartsharesystems.com>
>
>Thank you for resuming work on this. :-)