Sharing a list of names across API and CLI

[Morten Brørup]

> From: Robin Jarry [mailto:rjarry at redhat.com]
> Sent: Saturday, 22 August 2026 12.15
> 
> Morten Brørup, Aug 22, 2026 at 12:01:
> >> However, that means you need to expose "structured" information
> (i.e.
> >> key=value pairs) which may not fit with the "dump" functions from
> DPDK
> >> that seem to only expose text blobs.
> >
> > They only expose text blobs, not structured information.
> > So openmetrics is not an option for these.
> 
> But we could think of structuring these exports. I mean, the DPDK API
> can list the mempools, memzones, etc. Can't it? We could select which
> fields and properties we want to export in openmetrics. I can think of
> a few that would be useful even in production.
> 
> And that would fit the general idea of how statistics and metrics are
> already exported by grout.
> 
> > Since it's for development purposes only, I will compromise on user
> friendliness, and simply use "any string", so I don't need to
> synchronize the list of TYPE strings to the CLI.
> 
> In general, I much prefer avoiding raw text blobs returned by the API.
> I know it would be too much work to structure these messages (and
> probably not worth the effort).
> 
> Don't you think we could settle on something around openmetrics?

The DPDK dumps are designed for human consumption, and have very little formatting in common.

If we want data for openmetrics, we must to use other APIs than the dumps.
Sometimes, the format of the dump output changes.
And we cannot impose API stability requirements on DPDK dump output format.

Short term, I want a fast and easily implementable solution to expose a lot of information for development purposes.
The dumps are good for this.

Long term, we should absolutely expose relevant data for openmetrics.
(Our current StraightShaper also has structured APIs for streaming metrics into a time series database like InfluxDB/Grafana, used in production by ISPs to visualize network performance and make decisions about network/bandwidth optimization. Being able to visualize data is a highly valuable tool in production.)

> 
> --
> Robin
> 
> # Not affiliated with the American Red Cross.