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 <[email protected]> wrote: > > > > 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]> > > 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
