[v2,0/3] app/testpmd: qualify Rx/Tx profiling data on burst size

  There is the CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES configuration
parameter enabling the lightweight profiler for the forwarding
routines that provides the time spent in the routines and estimates
the CPU cycles required to process one packet.

It would be good to have separated data for the Rx and Tx directions.
Beside this, the performance depends on the actual burst size, the profiling
data per burst size are meaningful and would help detect the performance
anomalies.

To control this profiling statistics the new testpmd command is introduced:

  set fwdprof (flags)

This command controls which profiling statistics is being gathered
in runtime:

- bit 0 - enables profiling the entire forward routine, counts the ticks
          spent in the forwarding routine, is set by default. Provides
	  the same data as previous implementation.

- bit 1 - enables gathering the profiling data for the transmit datapath,
          counts the ticks spent within rte_eth_tx_burst() routine,
          is cleared by default, extends the existing statistics.

- bit 2 - enables gathering the profiling data for the receive datapath,
          counts the ticks spent within	rte_eth_rx_burst() routine,
	  is cleared by default, extends the existing statistics.

Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

---
v2: - run time flags instead of compile time configuration
    - detailed statistics per burst size

v1: http://patches.dpdk.org/patch/55407/

Viacheslav Ovsiienko (3):
  app/testpmd: add profiling flags set command
  app/testpmd: gather Rx and Tx routines profiling
  app/testpmd: qualify profiling statistics on burst size

 app/test-pmd/cmdline.c                      | 15 ++++++++
 app/test-pmd/config.c                       | 10 +++++
 app/test-pmd/csumonly.c                     | 26 ++++++-------
 app/test-pmd/flowgen.c                      | 26 ++++++-------
 app/test-pmd/icmpecho.c                     | 27 +++++++-------
 app/test-pmd/iofwd.c                        | 26 ++++++-------
 app/test-pmd/macfwd.c                       | 26 ++++++-------
 app/test-pmd/macswap.c                      | 26 ++++++-------
 app/test-pmd/rxonly.c                       | 14 ++-----
 app/test-pmd/softnicfwd.c                   | 26 ++++++-------
 app/test-pmd/testpmd.c                      | 52 ++++++++++++++++++++++----
 app/test-pmd/testpmd.h                      | 58 ++++++++++++++++++++++++++++-
 app/test-pmd/txonly.c                       | 25 ++++++-------
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 22 +++++++++++
 14 files changed, 256 insertions(+), 123 deletions(-)
  

19/03/2020 14:50, Viacheslav Ovsiienko:
> There is the CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES configuration
> parameter enabling the lightweight profiler for the forwarding
> routines that provides the time spent in the routines and estimates
> the CPU cycles required to process one packet.
> 
> It would be good to have separated data for the Rx and Tx directions.
> Beside this, the performance depends on the actual burst size, the profiling
> data per burst size are meaningful and would help detect the performance
> anomalies.
> 
> To control this profiling statistics the new testpmd command is introduced:
> 
>   set fwdprof (flags)
> 
> This command controls which profiling statistics is being gathered
> in runtime:
> 
> - bit 0 - enables profiling the entire forward routine, counts the ticks
>           spent in the forwarding routine, is set by default. Provides
> 	  the same data as previous implementation.
> 
> - bit 1 - enables gathering the profiling data for the transmit datapath,
>           counts the ticks spent within rte_eth_tx_burst() routine,
>           is cleared by default, extends the existing statistics.
> 
> - bit 2 - enables gathering the profiling data for the receive datapath,
>           counts the ticks spent within	rte_eth_rx_burst() routine,
> 	  is cleared by default, extends the existing statistics.

Please can you rename bit 1 to Rx, and bit 2 to Tx,
and implement configuration with text parsing instead of obscure bitflags?
It would be more user-friendly, thanks.