Kevin Laatz, Jan 18, 2023 at 10:42:
> Hi Robin,
>
> Thanks for taking the time to work on this. It is a good implementation
> for debug use-cases.
>
> I have 2 suggestions which would improve the usability of the data:
> 1. Could we make the lcore_id paramater on /eal/lcore/info optional?
> This would allow users to read info for all lcores in the application at
> once.
I don't think it would be a good thing since it would require returning
a different data format depending the parameter is specifier or not.
Probably adding another endpoint /eal/lcore/info_all that returns a list
of /eal/lcore/info (one for every lcore) would be better.
> 2. Could we add 2 additional telemetry endpoints? One which returns an
> array of busy_cycles values and the other returns an array of
> total_cycles values. These arrays could be used in conjunction with the
> /eal/lcore/list endpoint to quickly read the usage related metrics. I've
> included an example diff below [1].
>
> We have a use-case beyond debugging in which we read telemetry every few
> milliseconds. From a performance point of view, adding the 2 additional
> endpoints would be very beneficial.
If we add /eal/lcore/info_all you would have all this without two
additional endpoints. I don't think that calling it every few
milliseconds and extracting the {busy,total}_cycles values would be
a problem.
I can add another patch in the series but I would prefer not changing
the format at the last minute.
Would that be ok?
