Sharing a list of names across API and CLI

[Morten Brørup]

> From: Morten Brørup
> Sent: Saturday, 22 August 2026 12.33
> 
> > 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.

Picking up this mail thread, the resulting patch is here:
https://patchwork.dpdk.org/project/grout/patch/20260823131730.466752-1-mb@smartsharesystems.com/

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