> From: Anatoly Burakov [mailto:anatoly.bura...@intel.com] > Sent: Friday, 15 July 2022 15.13 > > Currently, there is no way to measure lcore 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 busyness. > > The busyness is calculated by relying on the fact that most DPDK API's > will poll for packets.
This is an "alternative fact"! Only run-to-completion applications polls for RX. Pipelined applications do not poll for packets in every pipeline stage. > Empty polls can be counted as "idle", while > non-empty polls can be counted as busy. To measure lcore 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 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 telemetry 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 > also possible to disable it at compile time by commenting out > RTE_LCORE_BUSYNESS from build config. Since all of this can be completely disabled at build time, and thus has exactly zero performance impact, I will not object to this patch. > > This patch also adds a telemetry endpoint to report lcore busyness, as > well as telemetry endpoints to enable/disable lcore telemetry. > > 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> > --- > > Notes: > We did a couple of quick smoke tests to see if this patch causes > any performance > degradation, and it seemed to have none that we could measure. > Telemetry can be > disabled at compile time via a config option, while at runtime it > can be > disabled, seemingly at a cost of one additional branch. > > That said, our benchmarking efforts were admittedly not very > rigorous, so > comments welcome! This patch does not reflect lcore business, it reflects some sort of ingress activity level. All the considerations regarding non-intrusiveness and low overhead are good, but everything in this patch needs to be renamed to reflect what it truly does, so it is clear that pipelined applications cannot use this telemetry for measuring lcore business (except on the ingress pipeline stage). It's a shame that so much effort clearly has gone into this patch, and no one stopped to consider pipelined applications. :-(
