OK, what do you think about this:
#ifdef RTE_TEST_PMD_RECORD_CORE_CYCLES
if (record_cycle & RECORD_TX_CORE_CYCLES) {
.. do measurement stuff ..
}
#endif
+ add some new command to config in runtime: "set record_cycle 3"
We keep existing RTE_TEST_PMD_RECORD_CORE_CYCLES, do not introduce
new build-time configs and get some new runtime configuring.
WBR,
Slava
> -----Original Message-----
> From: Bruce Richardson <bruce.richard...@intel.com>
> Sent: Wednesday, June 26, 2019 16:21
> To: Slava Ovsiienko <viachesl...@mellanox.com>
> Cc: dev@dpdk.org; bernard.iremon...@intel.com; ferruh.yi...@intel.com
> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: add profiling for Rx/Tx burst
> routines
>
> On Wed, Jun 26, 2019 at 01:19:24PM +0000, Slava Ovsiienko wrote:
> > Hi, Bruce
> >
> > Do you mean using "if (core_rx_cycle_enabled) {...}" instead of #ifdef ?
> >
> > No, I did not try runtime control settings.
> > Instead I compared performance with all RECORD_CORE_XX_CYCLES
> options
> > enabled/disabled builds and have seen the ~1-2% performance difference
> on my setups (mainly fwd txonly with retry).
> > So, ticks measuring is not free.
> >
> > With best regards,
> > Slava
> >
> Yes, I realise that measuring ticks is going to have a performance impact.
> However, what I was referring to was exactly the former - using an "if"
> rather than an "ifdef". I would hope with ticks disable using this option
> shows
> no perf impact, and we can reduce the use of build-time configs.
>
> /Bruce
