RE: [PATCH v1 1/2] eal: add lcore busyness telemetry

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> Sent: Sunday, 17 July 2022 05.10
> 
> <snip>
> 
> > Subject: RE: [PATCH v1 1/2] eal: add lcore busyness telemetry
> >
> > > From: Anatoly Burakov [mailto:anatoly.burakov@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.
> I guess you meant, poll for packets from NIC. They still need to
> receive packets from queues. We could do a similar thing for rte_ring
> APIs.

But it would mix apples, pears and bananas.

Let's say you have a pipeline with three ingress preprocessing threads, two advanced packet processing threads in the next pipeline stage and one egress thread as the third pipeline stage.

Now, the metrics reflects busyness for six threads, but three of them are apples, two of them are pears, and one is bananas.

I just realized another example, where this patch might give misleading results on a run-to-completion application:

One thread handles a specific type of packets received on an Ethdev ingress queue set up by the rte_flow APIs, and another thread handles ingress packets from another Ethdev ingress queue. E.g. the first queue may contain packets for well known flows, where packets can be processed quickly, and the other queue for other packets requiring more scrutiny. Both threads are run-to-completion and handle Ethdev ingress packets.

*So: Only applications where the threads perform the exact same task can use this patch.*

Also, rings may be used for other purposes than queueing packets between pipeline stages. E.g. our application uses rings for fast bulk allocation and freeing of other resources.