<html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <div class="moz-cite-prefix">On 16/09/2022 13:35, Kevin Laatz wrote: </div> <blockquote type="cite" cite="mid:8646ba9f-a6bc-1bd0-0cf5-349268f4032c@intel.com">On 14/09/2022 15:33, Stephen Hemminger wrote: <blockquote type="cite">On Wed, 14 Sep 2022 10:29:25 +0100 Kevin Laatz <a class="moz-txt-link-rfc2396E" href="mailto:kevin.laatz@intel.com"><kevin.laatz@intel.com></a> wrote: <blockquote type="cite">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. </blockquote> 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. </blockquote> 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). </blockquote> 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. </body> </html>