[PATCH v7 0/4] Add lcore poll busyness telemetry
Kevin Laatz
kevin.laatz at intel.com
Fri Sep 16 16:10:28 CEST 2022
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 <kevin.laatz at 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).
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20220916/d2f1d3f4/attachment-0001.htm>
More information about the dev
mailing list