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