On 16/09/2022 13:35, Kevin Laatz wrote: > On 14/09/2022 15:33, Stephen Hemminger wrote: >> On Wed, 14 Sep 2022 10:29:25 +0100 >> Kevin Laatz 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). > Worth mentioning as well, is that when lcore poll busyness is enabled at compile-time and disabled at run-time, we see *zero *performance impact.