Thu, Mar 12, 2026 at 03:19:16PM +0100, kuba@kernel.org wrote:

On Thu, 12 Mar 2026 09:34:52 +0100 Jiri Pirko wrote:

quoted

quoted

quoted

devlink resource show scope dev
pci/0000:03:00.0:
<resource>
pci/0000:03:00.1:
<resource>  

LGTM  

I don't see the benefit of exposing the scope to the user to be honest.
I mean, dump would show all, dump with "dev" handle would be used as a
selector to dump only things related to "dev". What is the use case of
this "scope" granularity?

If we follow the logic that dump should show the user relevant
resources, no matter which sub-object they are attached to -
having a dev specified should only filter the objects to match
the dev, including resources which are on ports of that dev.

IDK if there's a strong use case for allowing the user to set
scope on CLI but also - I don't see why not?

At least some small sense of consistency with other dumps? Health
reporter and region does not have scope and output mixture of dev-based
and port-based objects. Why to confuse user?

quoted

quoted

quoted

For the do-it command:
devlink resource show pci/0000:03:00.0
pci/0000:03:00.0:
<resource>
pci/0000:03:00.0/196608:
<port-resource>
pci/0000:03:00.0/196609:
<port-resource>

devlink resource show pci/0000:03:00.0 scope port
pci/0000:03:00.0/196608:
<port-resource>
pci/0000:03:00.0/196609:
<port-resource>

devlink resource show pci/0000:03:00.0  scope dev
pci/0000:03:00.0:
<resource>  

Do we have to touch doit? Maybe we should let doit be what it is now
and consider it legacy going forward? doit which is in fact a filtered
dump is a bit of a mistake in the first place, from Netlink's
perspective.  

I don't think we should. If user wants doit, he is going to specify the
object (dev/port). If user is interested only in things related to
single device, he should do dump with selector (dev).

Could you confirm that you're agreeing that we should leave doit as is?
I'm not 100% sure after reading this twice :)

Yes.