Re: [PATCH v2 2/2] ethdev: add telemetry endpoint for list names

[Bruce Richardson <bruce.richardson@intel.com>]

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 <mb@smartsharesystems.com> wrote:
> 
> > > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > > 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 <mb@smartsharesystems.com>
> 
> 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