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

["Morten Brørup" <mb@smartsharesystems.com>]

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