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

[Burakov, Anatoly]

On 17-Jul-22 10:56 AM, Morten Brørup wrote:
>> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli at 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 at 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.

Ring API is already instrumented to report telemetry in the same way, so 
any rte_ring-based pipeline will be able to track it. Obviously, 
non-DPDK API's will have to be instrumented too, we really can't do 
anything about that from inside DPDK.

> 
> 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.*

I do not see how that follows. I think you're falling for a "it's not 
100% useful, therefore it's 0% useful" fallacy here. Some use cases 
would obviously make telemetry more informative than others, that's 
true, however I do not see how it's a mandatory requirement for lcore 
busyness to report the same thing. We can document the limitations and 
assumptions made, can we not?

It is true that this patchset is mostly written from the standpoint of a 
run-to-completion application, but can we improve it? What would be your 
suggestions to make it better suit use cases you are familiar with?

> 
> 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.
> 

Well, this is the tradeoff for simplicity. Of course we could add all 
sorts of stuff like dynamic enable/disable of this and that and the 
other... but the end goal was something easy and automatic and that 
doesn't require any work to implement, not something that suits 100% of 
the cases 100% of the time. Having such flexibility as you described 
comes at a cost that this patch was not meant to pay!

-- 
Thanks,
Anatoly