Wed, Mar 04, 2026 at 11:05:06AM +0100, jiri@resnulli.us wrote:

Tue, Mar 03, 2026 at 04:26:40AM +0100, kuba@kernel.org wrote:

quoted

On Fri, 27 Feb 2026 00:19:06 +0200 Tariq Toukan wrote:

quoted

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?

quoted

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.