On 03/09/2022 14:33, Jerin Jacob wrote:
On Fri, Sep 2, 2022 at 9:26 PM Kevin Laatz <kevin.la...@intel.com> wrote:
From: Anatoly Burakov <anatoly.bura...@intel.com>

Currently, there is no way to measure lcore poll busyness in a passive way,
without any modifications to the application. This patch adds a new EAL API
that will be able to passively track core polling busyness.

The poll busyness is calculated by relying on the fact that most DPDK API's
will poll for work (packets, completions, eventdev events, etc). Empty
polls can be counted as "idle", while non-empty polls can be counted as
busy. To measure lcore poll busyness, we simply call the telemetry
timestamping function with the number of polls a particular code section
has processed, and count the number of cycles we've spent processing empty
bursts. The more empty bursts we encounter, the less cycles we spend in
"busy" state, and the less core poll busyness will be reported.

In order for all of the above to work without modifications to the
application, the library code needs to be instrumented with calls to the
lcore telemetry busyness timestamping function. The following parts of DPDK
are instrumented with lcore poll busyness timestamping calls:

- All major driver API's:
   - ethdev
   - cryptodev
   - compressdev
   - regexdev
   - bbdev
   - rawdev
   - eventdev
   - dmadev
- Some additional libraries:
   - ring
   - distributor

To avoid performance impact from having lcore telemetry support, a global
variable is exported by EAL, and a call to timestamping function is wrapped
into a macro, so that whenever telemetry is disabled, it only takes one
additional branch and no function calls are performed. It is disabled at
compile time by default.

This patch also adds a telemetry endpoint to report lcore poll busyness, as
well as telemetry endpoints to enable/disable lcore telemetry. A
documentation entry has been added to the howto guides to explain the usage
of the new telemetry endpoints and API.

Signed-off-by: Kevin Laatz <kevin.la...@intel.com>
Signed-off-by: Conor Walsh <conor.wa...@intel.com>
Signed-off-by: David Hunt <david.h...@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.bura...@intel.com>
This version looks good to me. Thanks for this new feature.

I think, we need to add a UT for this new rte_lcore_poll_* APIs also
add a performance test case to measure the cycles for
RTE_LCORE_POLL_BUSYNESS_TIMESTAMP [1]

[1]
Reference performance test application for trace: app/test/test_trace_perf.c

Thanks for reviewing, Jerin.

I'll look into adding a UT, thanks!

Reply via email to