>-----Original Message-----
>From: Stephen Hemminger <[email protected]>
>Sent: Friday, October 11, 2024 4:19 PM
>To: Konstantin Ananyev <[email protected]>
>Cc: Tomasz Duszynski <[email protected]>; Thomas Monjalon
><[email protected]>;
>[email protected]; [email protected]; [email protected];
>[email protected]; Jerin
>Jacob <[email protected]>; [email protected];
>[email protected];
>[email protected]; [email protected]; [email protected]
>Subject: [EXTERNAL] Re: [PATCH v14 1/4] lib: add generic support for reading
>PMU events
>
>On Fri, 11 Oct 2024 11: 56: 04 +0000 Konstantin Ananyev <konstantin. ananyev@
>huawei. com> wrote: >
>> + * > > + * @return > > + * 0 in case of success, negative value otherwise.
>> > > + */ > >
>+__rte_experimental
>On Fri, 11 Oct 2024 11:56:04 +0000
>Konstantin Ananyev <[email protected]> wrote:
>
>> > + *
>> > + * @return
>> > + * 0 in case of success, negative value otherwise.
>> > + */
>> > +__rte_experimental
>> > +int
>> > +rte_pmu_init(void);
>> > +
>> > +/**
>> > + * @warning
>> > + * @b EXPERIMENTAL: this API may change without prior notice
>> > + *
>> > + * Finalize PMU library. This should be called after PMU counters are no
>> > longer being read.
>> > + */
>> > +__rte_experimental
>> > +void
>> > +rte_pmu_fini(void);
>>
>> Hmm..., why _fini_() is allowed to be called directly while _init_() doesn't?
>
>Is this handled by destructor, called from rte_eal_cleanup() and/or testpmd?
If fast tracepoint is enabled then this is called by eal_trace_fini() which is
called by eal_trace_cleanup().
If fast tracepoint is disabled user should call it himself. Though, that
counter reading works best with fast trace point because everything is handled
automatically.
