08/04/2020 18:49, Ciara Power: > This patchset extensively reworks the telemetry library adding new > functionality and simplifying much of the existing code, while > maintaining backward compatibility. > > This work is based on the previously sent RFC for a "process info" > library: https://patchwork.dpdk.org/project/dpdk/list/?series=7741 > However, rather than creating a new library, this patchset takes > that work and merges it into the existing telemetry library, as > mentioned above. > > The telemetry library as shipped in 19.11 is based upon the metrics > library and outputs all statistics based on that as a source. However, > this limits the telemetry output to only port-level statistics > information, rather than allowing it to be used as a general scheme for > telemetry information across all DPDK libraries. > > With this patchset applied, rather than the telemetry library being > responsible for pulling ethdev stats and pushing them into the metrics > library for retrieval later, each library e.g. ethdev, rawdev, and even > the metrics library itself (for backwards compatiblity) now handle their > own stats. Any library or app can register a callback function with > telemetry, which will be called if requested by the client connected via > the telemetry socket. The callback function in the library/app then > formats its stats, or other data, into a JSON string, and returns it to > telemetry to be sent to the client.
I think this is a global need in DPDK, and it is usually called RPC, IPC or control messaging. We had a similar need for multi-process communication, thus rte_mp IPC. We also need a control channel for user configuration applications. We also need to control some features like logging or tracing. In my opinion, it is time to introduce a general control channel in DPDK. The application must be in the loop of the control mechanism. Making such channel standard will ease application adoption. Please read some comments here: http://inbox.dpdk.org/dev/2580933.jp2sp48Hzj@xps/
