On Wed, May 20, 2026 at 03:29:36PM +0200, Morten Brørup wrote:
> > From: Chengwen Feng [mailto:[email protected]]
> > Sent: Wednesday, 20 May 2026 11.38
> >
> > Add /ethdev/list_names telemetry endpoint which returns a dictionary
> > keyed by port ID with device name as the value, so users can
> > identify ports by name directly from the telemetry output.
> >
> > Original /ethdev/list output:
> > {"/ethdev/list": [0, 1]}
> >
> > New /ethdev/list_names output:
> > {"/ethdev/list_names": {"0": "0000:7d:00.0",
> > "1": "0000:7d:00.1"}}
> >
>
> <rant>
>
> Unfortunately, the telemetry protocol in DPDK is not using a common design,
> but takes parameters specific to each path.
> It should have used OData or something similar, to standardize listing,
> filtering, etc.
> Then we could have queried this like:
> /ethdev/info?$select=port_id,name
If you are up for implementing something like that, it should be possible
to have syntax like the above work alongside our existing syntax too.
The current telemetry scheme was set up with the overarching objective
being simplicity.
> And return something like:
> [
> {
> "port_id": 0,
> "name": "0000:7d:00.0"
> },
> {
> "port_id": 1,
> "name": "0000:7d:00.1"
> }
> ]
> or:
> [
> {
> 0,
> "0000:7d:00.0"
> },
> {
> 1,
> "0000:7d:00.1"
> }
> ]
>
> But now we are stuck with what we have.
>
> </rant>
>
> So /etdev/list_names is OK.
>
> I'm not really familiar with the DPDK telemetry, so I wonder if indexed
> arrays are normally returned as an object, like in this patch?
>
> I would have expected a list function (such as list_names) to return an array.
> Either a simple list:
> {
> "/ethdev/list_names":
> [
> "0000:7d:00.0",
> "0000:7d:00.1"
> ]
> }
>
I think it would prefer this, but it does get a bit harder to read with a
long list.
> Or a list of objects:
> {
> "/ethdev/list_names":
> [
> {
> "port_id": 0,
> "name": "0000:7d:00.0"
> },
> {
> "port_id": 1,
> "name": "0000:7d:00.1"
> }
> ]
> }
>
Agree that this also would be slightly better.
However, a *completely* different approach would be to instead solve this
issue by adding additional functionality to the interactive telemetry
script itself. After all, the data for the list of names of ethdevs is
already available from the telemetry endpoints already present in DPDK. All
we need to do is to extend the python script to have "virtual endpoints" if
you will, which do the necessary queries in the background and then present
the data to the user. I think that would be a cleaner approach to things
like this, rather than always adding more C code.
/Bruce
