On 5/21/2026 11:44 PM, Bruce Richardson wrote: > 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.
Great With the newly introduced FOREACH compound query capability, the port ID and device name mapping can be fully acquired by existing telemetry commands. The new command satisfies my original requirement perfectly. > > /Bruce > > [1] https://patches.dpdk.org/project/dpdk/list/?series=38197 >
