Wed, Mar 04, 2026 at 11:05:06AM +0100, [email protected] wrote: >Tue, Mar 03, 2026 at 04:26:40AM +0100, [email protected] wrote: >>On Fri, 27 Feb 2026 00:19:06 +0200 Tariq Toukan wrote: >>> With this series, users can query per-port resources: >>> >>> $ devlink port resource show pci/0000:03:00.0/196608 >>> pci/0000:03:00.0/196608: >>> name max_SFs size 20 unit entry >>> >>> $ devlink port resource show >>> pci/0000:03:00.0/196608: >>> name max_SFs size 20 unit entry >>> pci/0000:03:00.1/262144: >>> name max_SFs size 20 unit entry >> >>Code LGTM, I have a question about having a new cmd, tho. >> >>Does it matter to the user how the resource is scoped? >>Whether the resource is at the instance level or at the port level? >> >>I worry we are mechanically following the design of other commands. >>Since the dump handler is new we could just dump resources with port-id >>there. No existing user space may be using it. Alternatively we could >>add a new attribute to select a bitmask of which scope user wants to >>dump. > >You can specify what you want to dump with dump selectors. For example, >if you are interensted only in port of specific devlink. That should be >enough for most of the cases, no? > >> >>I have a strong suspicion that the user will want to access all >>resources of a device. `devlink resource show [$dev]` should dump >>all resources devlink knows about, including port ones. >> >>What's the reason for the new command? > >You are right, one cmd would do. Good thing someone forgot to implement >dump for it :)
On a second thought, if we merge multiple objects into one dump, how does this extend? I mean, the userspace has to check there are no extra attributes, as they may be used as a handle to another new object introduced in the future... Idk, it's a bit odd.
