Thu, Mar 12, 2026 at 03:19:16PM +0100, [email protected] wrote: >On Thu, 12 Mar 2026 09:34:52 +0100 Jiri Pirko wrote: >> >> 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? > >> >> 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.
