[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 at 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
>