[dpdk-dev] [PATCH v2 00/16] update and simplify telemetry library.

[Wiles, Keith]

> On Apr 10, 2020, at 5:49 AM, Morten Brørup <mb at smartsharesystems.com> wrote:
> 
>> From: Ciara Power [mailto:ciara.power at intel.com]
>> Sent: Wednesday, April 8, 2020 6:50 PM
>> 
>> 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.
> 
> Great. Standardization across libraries is a good improvement.
> 
>> 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 am strongly opposed to using JSON as the standard format in DPDK, and instead prefer a binary format with zero (or minimal) type conversion.
> 
> Here is one reason why I dislike JSON for this: A part of our application samples 100k+ counters every second to be able to provide drill-down statistics through the GUI. Converting these counters from uint64_t to JSON and back to uint64_t for data processing is not going to fly. And I assume that we are not the only company developing equipment with drill-down statistics.
> 
> I am aware that there is a difference between statistics for *drill-down and data processing* purposes and statistics for *telemetry eyeball viewing only* purposes, but the line is blurry, and I see a big risk of setting a path that leads to JSON being used in places where it shouldn't.
> 
> Here is another reason why I dislike JSON for this: JSON is fine for the LAMP stack with REST protocols. But other systems use other protocols with other formats, e.g. the TICK stack uses an even simpler text based format. So DPDK based systems supporting the TICK stack will need to convert to first JSON format (in the DPDK libraries), and then from JSON format to InfluxDB format (in the DPDK application).
> 
> I think that type conversion does not belong inside deep inside the DPDK libraries, but is a job for the DPDK application. However, DPDK could provide libraries for efficient bulk conversion to popular formats like JSON. And other formats, if they are relevant, e.g. ASN.1 used by old school SNMP.

I believe JSON has it place in this library and in DPDK as it is a good conversion tool and easy to utilize with a huge number of tools/languages. Binary output gets into endianness issues and a number of other problems, so I would not want all of the data exported from DPDK to be in binary format. If the layout of the structure changes then the code would need to know that on both side to be able to convert the data into the correct values.

With that stated, the new telemetry code allows the application to add new commands and with that you can create a binary set of commands along side the JSON or any other output format. With the new register command we can create say a ‘/ethdevraw/stats,X’ set of commands that can emit binary format.

Using this method we get the best of both worlds and when using languages like Go or Python to collect these stats we have a standard format for conversion. In Go it is pretty hard to do binary conversion and JSON conversion is just a few lines. JSON may not be the fastest, but if you are requesting stats faster than a second then use the raw commands to get the data, which anyone can add to its application or we can add them to DPDK as a standard command set.