> From: fengchengwen [mailto:[email protected]] > 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 <[email protected]> > > 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 > >
