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
> -----Original Message-----
> From: Bruce Richardson <bruce.richard...@intel.com>
> Sent: Wednesday, June 26, 2019 15:58
> 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 12:48:37PM +0000, Viacheslav Ovsiienko wrote:
> > There is the testpmd configuration option called
> > RTE_TEST_PMD_RECORD_CORE_CYCLES, if this one is turned on the
> testpmd
> > application measures the CPU clocks spent within forwarding loop. This
> > time is the sum of execution times of rte_eth_rx_burst(),
> > rte_eth_tx_burst(), rte_delay_us(),
> > rte_pktmbuf_free() and so on, depending on fwd mode set.
> >
> > While debugging and performance optimization of datapath burst
> > routines tt would be useful to see the pure execution times of these
> > ones. It is proposed to add separated profiling
> > options:
> >
> > CONFIG_RTE_TEST_PMD_RECORD_CORE_TX_CYCLES
> > enables gathering profiling data for transmit datapath,
> > ticks spent within rte_eth_tx_burst() routine
> >
> > CONFIG_RTE_TEST_PMD_RECORD_CORE_RX_CYCLES
> > enables gathering profiling data for receive datapath,
> > ticks spent within rte_eth_rx_burst() routine
> >
> > Signed-off-by: Viacheslav Ovsiienko <viachesl...@mellanox.com>
> > ---
> > RFC:
> >
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> >
> es.dpdk.org%2Fpatch%2F53704%2F&data=02%7C01%7Cviacheslavo%4
> 0mellan
> >
> ox.com%7Cbe154ad6d7b3460006ed08d6fa35de9c%7Ca652971c7d2e4d9ba
> 6a4d14925
> >
> 6f461b%7C0%7C0%7C636971506606185633&sdata=Y6UPuGwiYEeYrv3
> 9Sg3Wq9E2
> > GIBjyVa4mw31Et6FXKE%3D&reserved=0
> > ---
>
> Out of interest, did you try making these runtime rather than build-time
> options, and see if it makes any perf difference? Given the fact that we
> would have just two predictable branches per burst of packets, I'd expect the
> impact to me pretty minimal, if measurable at all.
>
> /Bruce
