[PATCH 0/2] enhance telemetry list endpoint with device name

[PATCH 0/2] enhance telemetry list endpoint with device name

[Chengwen Feng]

Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
only integer IDs, making it hard to identify devices. This series changes
both to output strings in "ID    NAME" format for better usability.

Chengwen Feng (2):
  dmadev: include device name in telemetry list output
  ethdev: include device name in telemetry list output

 lib/dmadev/rte_dmadev.c           | 17 ++++++++++++-----
 lib/ethdev/rte_ethdev_telemetry.c | 12 +++++++++---
 2 files changed, 21 insertions(+), 8 deletions(-)

-- 
2.17.1

[PATCH 1/2] dmadev: include device name in telemetry list output

[Chengwen Feng]

The /dmadev/list telemetry endpoint currently returns only device IDs
as integers. Enhance it to return strings in "ID    NAME" format so
users can identify devices by name directly from the telemetry output.

Original:
  {
    "/dmadev/list": [
      0,
      1
    ]
  }

After this commit:
  {
    "/dmadev/list": [
      "0    hisi_sec2-0-dma0",
      "1    hisi_sec2-0-dma1"
    ]
  }

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/dmadev/rte_dmadev.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index b75b4f9bd1..084e06a3da 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -1147,12 +1147,19 @@ dmadev_handle_dev_list(const char *cmd __rte_unused,
 		const char *params __rte_unused,
 		struct rte_tel_data *d)
 {
+	char id_name[RTE_TEL_MAX_STRING_LEN];
+	struct rte_dma_dev *dev;
 	int dev_id;
 
-	rte_tel_data_start_array(d, RTE_TEL_INT_VAL);
-	for (dev_id = 0; dev_id < dma_devices_max; dev_id++)
-		if (rte_dma_is_valid(dev_id))
-			rte_tel_data_add_array_int(d, dev_id);
+	rte_tel_data_start_array(d, RTE_TEL_STRING_VAL);
+	for (dev_id = 0; dev_id < dma_devices_max; dev_id++) {
+		if (!rte_dma_is_valid(dev_id))
+			continue;
+		dev = &rte_dma_devices[dev_id];
+		memset(id_name, 0, sizeof(id_name));
+		sprintf(id_name, "%d    %s", dev_id, dev->data->dev_name);
+		rte_tel_data_add_array_string(d, id_name);
+	}
 
 	return 0;
 }
@@ -1308,7 +1315,7 @@ dmadev_handle_dev_dump(const char *cmd __rte_unused,
 RTE_INIT(dmadev_init_telemetry)
 {
 	rte_telemetry_register_cmd("/dmadev/list", dmadev_handle_dev_list,
-			"Returns list of available dmadev devices by IDs. No parameters.");
+			"Returns list of available dmadev devices by ID-NAMEs. No parameters.");
 	rte_telemetry_register_cmd("/dmadev/info", dmadev_handle_dev_info,
 			"Returns information for a dmadev. Parameters: int dev_id");
 	rte_telemetry_register_cmd("/dmadev/stats", dmadev_handle_dev_stats,
-- 
2.17.1

[PATCH 2/2] ethdev: include device name in telemetry list output

[Chengwen Feng]

The /ethdev/list telemetry endpoint currently returns only port IDs
as integers. Enhance it to return strings in "ID    NAME" format so
users can identify ports by name directly from the telemetry output.

Original:
  {
    "/ethdev/list": [
      0,
      1
    ]
  }

After this commit:
  {
    "/ethdev/list": [
      "0    0000:7d:00.0",
      "1    0000:7d:00.1"
    ]
  }

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev_telemetry.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lib/ethdev/rte_ethdev_telemetry.c b/lib/ethdev/rte_ethdev_telemetry.c
index a910864bc5..f82b174110 100644
--- a/lib/ethdev/rte_ethdev_telemetry.c
+++ b/lib/ethdev/rte_ethdev_telemetry.c
@@ -53,11 +53,17 @@ eth_dev_handle_port_list(const char *cmd __rte_unused,
 		const char *params __rte_unused,
 		struct rte_tel_data *d)
 {
+	char id_name[RTE_TEL_MAX_STRING_LEN];
+	struct rte_eth_dev *dev;
 	int port_id;
 
-	rte_tel_data_start_array(d, RTE_TEL_INT_VAL);
-	RTE_ETH_FOREACH_DEV(port_id)
-		rte_tel_data_add_array_int(d, port_id);
+	rte_tel_data_start_array(d, RTE_TEL_STRING_VAL);
+	RTE_ETH_FOREACH_DEV(port_id) {
+		dev = &rte_eth_devices[port_id];
+		memset(id_name, 0, sizeof(id_name));
+		sprintf(id_name, "%d    %s", port_id, dev->data->name);
+		rte_tel_data_add_array_string(d, id_name);
+	}
 	return 0;
 }
 
-- 
2.17.1

RE: [PATCH 0/2] enhance telemetry list endpoint with device name

[Morten Brørup]

> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> Sent: Wednesday, 20 May 2026 05.57
> 
> Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
> only integer IDs, making it hard to identify devices. This series
> changes
> both to output strings in "ID    NAME" format for better usability.

For machine reading of the JSON output, it would be better returning an object with an integer and a string field, {ID, "NAME"}.

Re: [PATCH 0/2] enhance telemetry list endpoint with device name

[fengchengwen]

On 5/20/2026 1:40 PM, Morten Brørup wrote:
>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
>> Sent: Wednesday, 20 May 2026 05.57
>>
>> Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
>> only integer IDs, making it hard to identify devices. This series
>> changes
>> both to output strings in "ID    NAME" format for better usability.
> 
> For machine reading of the JSON output, it would be better returning an object with an integer and a string field, {ID, "NAME"}.

The TEL_DICT could do {"ID", "NAME"}, which like:
  "/ethdev/list": {
    "0": "0000:7d:00.0",
    "1": "0000:7d:00.1"
  }

Maybe we could add one TEL_INT_DICT which is int-value pairs, we may get:
  "/ethdev/list": {
    0: "0000:7d:00.0",
    1: "0000:7d:00.1"
  }

I prefer the first one, However, the capacity is reduced from 512 (RTE_TEL_MAX_ARRAY_ENTRIES) to 256 (RTE_TEL_MAX_DICT_ENTRIES), but I think it is enough.

What's your opinion?

> 
> 

Re: [PATCH 0/2] enhance telemetry list endpoint with device name

[Bruce Richardson]

On Wed, May 20, 2026 at 03:31:57PM +0800, fengchengwen wrote:
> On 5/20/2026 1:40 PM, Morten Brørup wrote:
> >> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> >> Sent: Wednesday, 20 May 2026 05.57
> >>
> >> Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
> >> only integer IDs, making it hard to identify devices. This series
> >> changes
> >> both to output strings in "ID    NAME" format for better usability.
> > 
> > For machine reading of the JSON output, it would be better returning an object with an integer and a string field, {ID, "NAME"}.
> 
> The TEL_DICT could do {"ID", "NAME"}, which like:
>   "/ethdev/list": {
>     "0": "0000:7d:00.0",
>     "1": "0000:7d:00.1"
>   }
> 
> Maybe we could add one TEL_INT_DICT which is int-value pairs, we may get:
>   "/ethdev/list": {
>     0: "0000:7d:00.0",
>     1: "0000:7d:00.1"
>   }
> 
> I prefer the first one, However, the capacity is reduced from 512 (RTE_TEL_MAX_ARRAY_ENTRIES) to 256 (RTE_TEL_MAX_DICT_ENTRIES), but I think it is enough.
> 
> What's your opinion?
> 

I'm not sure about this change at all. This change is only relevant for
those using the script interactively, for any other use, I would expect the
the /ethdev/list call would be followed by the /ethdev/info calls for each
port to get the name. That was the basic design in mind for this, the list
call was purely to provide the ids, any other info you make separate calls
for.

Also, while not officially part of the ABI of DPDK, I think it would be
wrong to go changing the types of the returned data from this /ethdev/list
call. Any user-written interfaces to telemetry will be relying on the
current behaviour to list and query ports. If you really want to have an
easy way to get the names of the ports, I suggest adding instead an
"/ethdev/list_names" API, which can either return the objects above, or
else simply an array of names.

/Bruce

[PATCH v2 0/2] Add list names telemetry endpoint

[Chengwen Feng]

Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
only integer IDs, making it hard to identify devices. This series add
list_names telemetry endpoint which output both IDs and its device's
name.

---
v2: Add new telemetry endpoint according Bruce's advise.

Chengwen Feng (2):
  dmadev: add telemetry endpoint for list names
  ethdev: add telemetry endpoint for list names

 lib/dmadev/rte_dmadev.c           | 23 +++++++++++++++++++++++
 lib/ethdev/rte_ethdev_telemetry.c | 21 +++++++++++++++++++++
 2 files changed, 44 insertions(+)

-- 
2.17.1

[PATCH v2 1/2] dmadev: add telemetry endpoint for list names

[Chengwen Feng]

Add /dmadev/list_names telemetry endpoint which returns a dictionary
keyed by device ID with device name as the value, so users can
identify devices by name directly from the telemetry output.

Original /dmadev/list output:
  {"/dmadev/list": [0, 1]}

New /dmadev/list_names output:
  {"/dmadev/list_names": {"0": "hisi_sec2-0-dma0",
  "1": "hisi_sec2-0-dma1"}}

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/dmadev/rte_dmadev.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index b75b4f9bd1..98ef7e2b93 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -1157,6 +1157,27 @@ dmadev_handle_dev_list(const char *cmd __rte_unused,
 	return 0;
 }
 
+static int
+dmadev_handle_dev_list_names(const char *cmd __rte_unused,
+		const char *params __rte_unused,
+		struct rte_tel_data *d)
+{
+	char id_str[RTE_TEL_MAX_STRING_LEN];
+	struct rte_dma_dev *dev;
+	int dev_id;
+
+	rte_tel_data_start_dict(d);
+	for (dev_id = 0; dev_id < dma_devices_max; dev_id++) {
+		if (!rte_dma_is_valid(dev_id))
+			continue;
+		dev = &rte_dma_devices[dev_id];
+		sprintf(id_str, "%d", dev_id);
+		rte_tel_data_add_dict_string(d, id_str, dev->data->dev_name);
+	}
+
+	return 0;
+}
+
 #define ADD_CAPA(td, dc, c) rte_tel_data_add_dict_int(td, dma_capability_name(c), !!(dc & c))
 
 static int
@@ -1309,6 +1330,8 @@ RTE_INIT(dmadev_init_telemetry)
 {
 	rte_telemetry_register_cmd("/dmadev/list", dmadev_handle_dev_list,
 			"Returns list of available dmadev devices by IDs. No parameters.");
+	rte_telemetry_register_cmd("/dmadev/list_names", dmadev_handle_dev_list_names,
+			"Returns dict of available dmadev devices by ID-NAMEs. No parameters.");
 	rte_telemetry_register_cmd("/dmadev/info", dmadev_handle_dev_info,
 			"Returns information for a dmadev. Parameters: int dev_id");
 	rte_telemetry_register_cmd("/dmadev/stats", dmadev_handle_dev_stats,
-- 
2.17.1

[PATCH v2 2/2] ethdev: add telemetry endpoint for list names

[Chengwen Feng]

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"}}

Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev_telemetry.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/lib/ethdev/rte_ethdev_telemetry.c b/lib/ethdev/rte_ethdev_telemetry.c
index a910864bc5..0e71419473 100644
--- a/lib/ethdev/rte_ethdev_telemetry.c
+++ b/lib/ethdev/rte_ethdev_telemetry.c
@@ -61,6 +61,24 @@ eth_dev_handle_port_list(const char *cmd __rte_unused,
 	return 0;
 }
 
+static int
+eth_dev_handle_port_list_names(const char *cmd __rte_unused,
+		const char *params __rte_unused,
+		struct rte_tel_data *d)
+{
+	char id_str[RTE_TEL_MAX_STRING_LEN];
+	struct rte_eth_dev *dev;
+	int port_id;
+
+	rte_tel_data_start_dict(d);
+	RTE_ETH_FOREACH_DEV(port_id) {
+		dev = &rte_eth_devices[port_id];
+		sprintf(id_str, "%d", port_id);
+		rte_tel_data_add_dict_string(d, id_str, dev->data->name);
+	}
+	return 0;
+}
+
 static int
 eth_dev_parse_hide_zero(const char *key, const char *value, void *extra_args)
 {
@@ -1548,6 +1566,9 @@ RTE_INIT(ethdev_init_telemetry)
 	rte_telemetry_register_cmd_arg("/ethdev/list",
 			eth_dev_telemetry_do, eth_dev_handle_port_list,
 			"Returns list of available ethdev ports. Takes no parameters");
+	rte_telemetry_register_cmd_arg("/ethdev/list_names",
+			eth_dev_telemetry_do, eth_dev_handle_port_list_names,
+			"Returns dict of available ethdev ports by ID-NAMEs. Takes no parameters");
 	rte_telemetry_register_cmd_arg("/ethdev/stats",
 			eth_dev_telemetry_do, eth_dev_handle_port_stats,
 			"Returns the common stats for a port. Parameters: int port_id");
-- 
2.17.1

RE: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names

[Morten Brørup]

> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> 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
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"
	]
}

Or a list of objects:
{
	"/ethdev/list_names":
	[
		{
			"port_id": 0,
			"name": "0000:7d:00.0"
		},
		{
			"port_id": 1,
			"name": "0000:7d:00.1"
		}
	]
}

Re: [PATCH 0/2] enhance telemetry list endpoint with device name

[Stephen Hemminger]

On Wed, 20 May 2026 08:49:51 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:

> On Wed, May 20, 2026 at 03:31:57PM +0800, fengchengwen wrote:
> > On 5/20/2026 1:40 PM, Morten Brørup wrote:  
> > >> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > >> Sent: Wednesday, 20 May 2026 05.57
> > >>
> > >> Currently, the /dmadev/list and /ethdev/list telemetry endpoints return
> > >> only integer IDs, making it hard to identify devices. This series
> > >> changes
> > >> both to output strings in "ID    NAME" format for better usability.  
> > > 
> > > For machine reading of the JSON output, it would be better returning an object with an integer and a string field, {ID, "NAME"}.  
> > 
> > The TEL_DICT could do {"ID", "NAME"}, which like:
> >   "/ethdev/list": {
> >     "0": "0000:7d:00.0",
> >     "1": "0000:7d:00.1"
> >   }
> > 
> > Maybe we could add one TEL_INT_DICT which is int-value pairs, we may get:
> >   "/ethdev/list": {
> >     0: "0000:7d:00.0",
> >     1: "0000:7d:00.1"
> >   }
> > 
> > I prefer the first one, However, the capacity is reduced from 512 (RTE_TEL_MAX_ARRAY_ENTRIES) to 256 (RTE_TEL_MAX_DICT_ENTRIES), but I think it is enough.
> > 
> > What's your opinion?
> >   
> 
> I'm not sure about this change at all. This change is only relevant for
> those using the script interactively, for any other use, I would expect the
> the /ethdev/list call would be followed by the /ethdev/info calls for each
> port to get the name. That was the basic design in mind for this, the list
> call was purely to provide the ids, any other info you make separate calls
> for.
> 
> Also, while not officially part of the ABI of DPDK, I think it would be
> wrong to go changing the types of the returned data from this /ethdev/list
> call. Any user-written interfaces to telemetry will be relying on the
> current behaviour to list and query ports. If you really want to have an
> easy way to get the names of the ports, I suggest adding instead an
> "/ethdev/list_names" API, which can either return the objects above, or
> else simply an array of names.
> 
> /Bruce

The new wireshark extcap needs similar device list.
Ideally returning similar format to existing dpdk-dumpcap -D

Re: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names

[Bruce Richardson]

On Wed, May 20, 2026 at 03:29:36PM +0200, Morten Brørup wrote:
> > From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> > 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

Re: [PATCH 1/2] dmadev: include device name in telemetry list output

[Stephen Hemminger]

On Wed, 20 May 2026 11:56:40 +0800
Chengwen Feng <fengchengwen@huawei.com> wrote:

> After this commit:
>   {
>     "/dmadev/list": [
>       "0    hisi_sec2-0-dma0",
>       "1    hisi_sec2-0-dma1"
>     ]
>   }

That is awkward JSON. Better to not have the 0 and 1 prefixes.
Typical usage will read JSON in python and array index would
be implicit.

Re: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names

[fengchengwen]

Thanks for the feedback.

I intend to keep the current dict format. This concise ID-name mapping is quite
helpful and easy to read especially when there are massive ports, which is exactly
the main purpose why I submitted this patch.

In my opinion, adopting OData-style query would require architecture-level
refactoring of telemetry framework, which is way too heavy for this simple requirement.
For complex query demands, we can implement them by extending the upper-layer Python
telemetry script instead.

So I suggest we keep this simple form here.

Thanks.

On 5/20/2026 10:58 PM, Bruce Richardson wrote:
> On Wed, May 20, 2026 at 03:29:36PM +0200, Morten Brørup wrote:
>>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
>>> 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
> 

RE: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names

[Morten Brørup]

> From: fengchengwen [mailto:fengchengwen@huawei.com]
> Sent: Thursday, 21 May 2026 14.25
> 
> Thanks for the feedback.
> 
> I intend to keep the current dict format. This concise ID-name mapping
> is quite
> helpful and easy to read especially when there are massive ports, which
> is exactly
> the main purpose why I submitted this patch.
> 
> In my opinion, adopting OData-style query would require architecture-
> level
> refactoring of telemetry framework, which is way too heavy for this
> simple requirement.

Agree.
Refactoring the telemetry framework is different task, not related to this patch.

> For complex query demands, we can implement them by extending the
> upper-layer Python
> telemetry script instead.
> 
> So I suggest we keep this simple form here.

If it is generally acceptable for DPDK telemetry that a request for a list does not return a list type, but returns an object type with "index": "value" fields instead, then
Series-acked-by: Morten Brørup <mb@smartsharesystems.com>

> 
> Thanks.
> 
> On 5/20/2026 10:58 PM, Bruce Richardson wrote:
> > On Wed, May 20, 2026 at 03:29:36PM +0200, Morten Brørup wrote:
> >>> From: Chengwen Feng [mailto:fengchengwen@huawei.com]
> >>> 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
> >

Re: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names

[Stephen Hemminger]

On Thu, 21 May 2026 14:40:47 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:

> > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > Sent: Thursday, 21 May 2026 14.25
> > 
> > Thanks for the feedback.
> > 
> > I intend to keep the current dict format. This concise ID-name mapping
> > is quite
> > helpful and easy to read especially when there are massive ports, which
> > is exactly
> > the main purpose why I submitted this patch.
> > 
> > In my opinion, adopting OData-style query would require architecture-
> > level
> > refactoring of telemetry framework, which is way too heavy for this
> > simple requirement.  
> 
> Agree.
> Refactoring the telemetry framework is different task, not related to this patch.
> 
> > For complex query demands, we can implement them by extending the
> > upper-layer Python
> > telemetry script instead.
> > 
> > So I suggest we keep this simple form here.  
> 
> If it is generally acceptable for DPDK telemetry that a request for a list does not return a list type, but returns an object type with "index": "value" fields instead, then
> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>

It is necessary since port list may have holes due to hotplug or the ownership API.
It would be good to have a more complete query function that returns more about each ethdev.
I wouldn't worry about the size of the response. This is JSON and it is meant to be read by scripts not directly by humans.

Re: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names

[Bruce Richardson]

On Thu, May 21, 2026 at 07:37:16AM -0700, Stephen Hemminger wrote:
> On Thu, 21 May 2026 14:40:47 +0200
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > > Sent: Thursday, 21 May 2026 14.25
> > > 
> > > Thanks for the feedback.
> > > 
> > > I intend to keep the current dict format. This concise ID-name mapping
> > > is quite
> > > helpful and easy to read especially when there are massive ports, which
> > > is exactly
> > > the main purpose why I submitted this patch.
> > > 
> > > In my opinion, adopting OData-style query would require architecture-
> > > level
> > > refactoring of telemetry framework, which is way too heavy for this
> > > simple requirement.  
> > 
> > Agree.
> > Refactoring the telemetry framework is different task, not related to this patch.
> > 
> > > For complex query demands, we can implement them by extending the
> > > upper-layer Python
> > > telemetry script instead.
> > > 
> > > So I suggest we keep this simple form here.  
> > 
> > If it is generally acceptable for DPDK telemetry that a request for a list does not return a list type, but returns an object type with "index": "value" fields instead, then
> > Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
> 
> It is necessary since port list may have holes due to hotplug or the ownership API.
> It would be good to have a more complete query function that returns more about each ethdev.
> I wouldn't worry about the size of the response. This is JSON and it is meant to be read by scripts not directly by humans.

That's where I think we have a difference - if the output is meant to be
read by scripts, we should not need extra commands like this, since the
information is already available via existing commands. The only compelling
reason that I can see for adding a new command to return a set of ethdev
names is for human interactive use.

Personally, I think the output should be just used by other scripts, but
it does appear that this quick-and-dirty telemetry script is being used
extensively for human interactive querying. Therefore, I'm working on
extending the script to make it more useful for such cases. I'd prefer to
add the extra smarts into the script rather than seeing a proliferation of
endpoints providing the same data in different formats.

/Bruce

Re: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names

[Bruce Richardson]

On Thu, May 21, 2026 at 04:21:59PM +0100, Bruce Richardson wrote:
> On Thu, May 21, 2026 at 07:37:16AM -0700, Stephen Hemminger wrote:
> > On Thu, 21 May 2026 14:40:47 +0200 Morten Brørup
> > <mb@smartsharesystems.com> wrote:
> > 
> > > > From: fengchengwen [mailto:fengchengwen@huawei.com] Sent: Thursday,
> > > > 21 May 2026 14.25
> > > > 
> > > > Thanks for the feedback.
> > > > 
> > > > I intend to keep the current dict format. This concise ID-name
> > > > mapping is quite helpful and easy to read especially when there are
> > > > massive ports, which is exactly the main purpose why I submitted
> > > > this patch.
> > > > 
> > > > In my opinion, adopting OData-style query would require
> > > > architecture- level refactoring of telemetry framework, which is
> > > > way too heavy for this simple requirement.  
> > > 
> > > Agree.  Refactoring the telemetry framework is different task, not
> > > related to this patch.
> > > 
> > > > For complex query demands, we can implement them by extending the
> > > > upper-layer Python telemetry script instead.
> > > > 
> > > > So I suggest we keep this simple form here.  
> > > 
> > > If it is generally acceptable for DPDK telemetry that a request for a
> > > list does not return a list type, but returns an object type with
> > > "index": "value" fields instead, then Series-acked-by: Morten Brørup
> > > <mb@smartsharesystems.com>
> > 
> > It is necessary since port list may have holes due to hotplug or the
> > ownership API.  It would be good to have a more complete query function
> > that returns more about each ethdev.  I wouldn't worry about the size
> > of the response. This is JSON and it is meant to be read by scripts not
> > directly by humans.
> 
> That's where I think we have a difference - if the output is meant to be
> read by scripts, we should not need extra commands like this, since the
> information is already available via existing commands. The only
> compelling reason that I can see for adding a new command to return a set
> of ethdev names is for human interactive use.
> 
> Personally, I think the output should be just used by other scripts, but
> it does appear that this quick-and-dirty telemetry script is being used
> extensively for human interactive querying. Therefore, I'm working on
> extending the script to make it more useful for such cases. I'd prefer to
> add the extra smarts into the script rather than seeing a proliferation
> of endpoints providing the same data in different formats.
>
Here [1] is my proposed generalised solution, quickly prototyped with copilot,
composed of two parts: firstly, support for querying values across a range
of ports using a foreach command, and then secondly, support for aliases to
make the use of those foreach commands easier on the user. It's not
intended as a mergable set of patches as-is, but rather to demonstrate how
we might be able to come up with a more general solution (that keeps to the
DRY principle) entirely within the python script rather than extending the
C code.

/Bruce

[1] https://patches.dpdk.org/project/dpdk/list/?series=38197 

Re: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names

[fengchengwen]

On 5/21/2026 11:44 PM, Bruce Richardson wrote:
> On Thu, May 21, 2026 at 04:21:59PM +0100, Bruce Richardson wrote:
>> On Thu, May 21, 2026 at 07:37:16AM -0700, Stephen Hemminger wrote:
>>> On Thu, 21 May 2026 14:40:47 +0200 Morten Brørup
>>> <mb@smartsharesystems.com> wrote:
>>>
>>>>> From: fengchengwen [mailto:fengchengwen@huawei.com] Sent: Thursday,
>>>>> 21 May 2026 14.25
>>>>>
>>>>> Thanks for the feedback.
>>>>>
>>>>> I intend to keep the current dict format. This concise ID-name
>>>>> mapping is quite helpful and easy to read especially when there are
>>>>> massive ports, which is exactly the main purpose why I submitted
>>>>> this patch.
>>>>>
>>>>> In my opinion, adopting OData-style query would require
>>>>> architecture- level refactoring of telemetry framework, which is
>>>>> way too heavy for this simple requirement.  
>>>>
>>>> Agree.  Refactoring the telemetry framework is different task, not
>>>> related to this patch.
>>>>
>>>>> For complex query demands, we can implement them by extending the
>>>>> upper-layer Python telemetry script instead.
>>>>>
>>>>> So I suggest we keep this simple form here.  
>>>>
>>>> If it is generally acceptable for DPDK telemetry that a request for a
>>>> list does not return a list type, but returns an object type with
>>>> "index": "value" fields instead, then Series-acked-by: Morten Brørup
>>>> <mb@smartsharesystems.com>
>>>
>>> It is necessary since port list may have holes due to hotplug or the
>>> ownership API.  It would be good to have a more complete query function
>>> that returns more about each ethdev.  I wouldn't worry about the size
>>> of the response. This is JSON and it is meant to be read by scripts not
>>> directly by humans.
>>
>> That's where I think we have a difference - if the output is meant to be
>> read by scripts, we should not need extra commands like this, since the
>> information is already available via existing commands. The only
>> compelling reason that I can see for adding a new command to return a set
>> of ethdev names is for human interactive use.
>>
>> Personally, I think the output should be just used by other scripts, but
>> it does appear that this quick-and-dirty telemetry script is being used
>> extensively for human interactive querying. Therefore, I'm working on
>> extending the script to make it more useful for such cases. I'd prefer to
>> add the extra smarts into the script rather than seeing a proliferation
>> of endpoints providing the same data in different formats.
>>
> Here [1] is my proposed generalised solution, quickly prototyped with copilot,
> composed of two parts: firstly, support for querying values across a range
> of ports using a foreach command, and then secondly, support for aliases to
> make the use of those foreach commands easier on the user. It's not
> intended as a mergable set of patches as-is, but rather to demonstrate how
> we might be able to come up with a more general solution (that keeps to the
> DRY principle) entirely within the python script rather than extending the
> C code.

Great

With the newly introduced FOREACH compound query capability, the port ID and
device name mapping can be fully acquired by existing telemetry commands.

The new command satisfies my original requirement perfectly.

> 
> /Bruce
> 
> [1] https://patches.dpdk.org/project/dpdk/list/?series=38197 
>