On 14/09/2022 15:33, Stephen Hemminger wrote:

On Wed, 14 Sep 2022 10:29:25 +0100
Kevin Laatz <kevin.laatz@intel.com> wrote:

Currently, there is no way to measure lcore polling busyness in a passive
way, without any modifications to the application. This patchset adds a new
EAL API that will be able to passively track core polling busyness. As part
of the set, new telemetry endpoints are added to read the generate metrics.

How much does measuring busyness impact performance??

In the past, calling rte_rdsc() would slow down packet rate
because it is stops CPU pipeline. Maybe better on more modern
processors, haven't measured it lately.

Hi Stephen,

I've run some 0.001% loss tests using 2x 100G ports, with 64B packets using testpmd for forwarding. Those tests show a ~2.7% performance impact when the lcore poll busyness feature is enabled vs compile-time disabled.
Applications with more compute intensive workloads should see less performance impact since the proportion of time spent time-stamping will be smaller.

In addition, a performance autotest has been added in this patchset which measures the cycles cost of calling the timestamp macro. Please feel free to test it on your system (lcore_poll_busyness_perf_autotest).