On Thu, May 21, 2026 at 04:21:59PM +0100, Bruce Richardson wrote: > 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. > Here [1] is my proposed generalised solution, quickly prototyped with copilot, composed of two parts: firstly, support for querying values across a range of ports using a foreach command, and then secondly, support for aliases to make the use of those foreach commands easier on the user. It's not intended as a mergable set of patches as-is, but rather to demonstrate how we might be able to come up with a more general solution (that keeps to the DRY principle) entirely within the python script rather than extending the C code.
/Bruce [1] https://patches.dpdk.org/project/dpdk/list/?series=38197
