Documentation/netlink/specs/devlink.yaml | 29 +- .../networking/devlink/devlink-resource.rst | 60 ++- .../net/ethernet/mellanox/mlx5/core/devlink.h | 4 + .../mellanox/mlx5/core/esw/devlink_port.c | 37 ++ drivers/net/netdevsim/dev.c | 23 +- drivers/net/netdevsim/netdevsim.h | 4 + include/net/devlink.h | 10 +- include/uapi/linux/devlink.h | 3 + net/devlink/devl_internal.h | 4 + net/devlink/netlink.c | 2 +- net/devlink/netlink_gen.c | 49 ++- net/devlink/netlink_gen.h | 8 +- net/devlink/port.c | 3 + net/devlink/resource.c | 366 +++++++++++++++--- .../drivers/net/netdevsim/devlink.sh | 53 ++- 15 files changed, 581 insertions(+), 74 deletions(-)
Hi, This series adds devlink per-port resource support. See detailed description by Or below [1]. Regards, Tariq [1] Currently, devlink resources are only available at the device level. However, some resources are inherently per-port, such as the maximum number of subfunctions (SFs) that can be created on a specific PF port. This limitation prevents user space from obtaining accurate per-port capacity information. This series adds infrastructure for per-port resources in devlink core and implements it in the mlx5 driver to expose the max_SFs resource on PF devlink ports. Patch #1 adds dump support for device-level resources Patch #2 adds selftest for resource dump Patch #3 adds dump to resource documentation Patch #4 refactors resource functions to be generic Patch #5 adds port-level resource registration infrastructure Patch #6 adds port resource netlink command Patch #7 registers SF resource on PF port representor in mlx5 Patch #8 adds devlink port resource registration to netdevsim for testing Patch #9 adds selftest for devlink port resources Patch #10 documents port-level resources 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 Userspace patches for iproute2: https://github.com/ohartoov/iproute2/tree/port_resource V3: - Add dump command for device-level resources. - Fix selftest to expect the "test_resource" registered by netdevsim instead of max_SFs. - Use a single netlink fill function for both device-level and port-level resources. - Fix documentation to refer to the GET command (kernel/netlink perspective) instead of show. - Link to V2: https://lore.kernel.org/all/20260205142833.1727929-1-tariqt@nvidia.com/ Or Har-Toov (10): devlink: Add dump support for device-level resources selftest: netdevsim: Add resource dump test devlink: Add dump to resource documentation devlink: Refactor resource functions to be generic devlink: Add port-level resource registration infrastructure devlink: Add port resource netlink command net/mlx5: Register SF resource on PF port representor netdevsim: Add devlink port resource registration selftest: netdevsim: Add devlink port resource test devlink: Document port-level resources Documentation/netlink/specs/devlink.yaml | 29 +- .../networking/devlink/devlink-resource.rst | 60 ++- .../net/ethernet/mellanox/mlx5/core/devlink.h | 4 + .../mellanox/mlx5/core/esw/devlink_port.c | 37 ++ drivers/net/netdevsim/dev.c | 23 +- drivers/net/netdevsim/netdevsim.h | 4 + include/net/devlink.h | 10 +- include/uapi/linux/devlink.h | 3 + net/devlink/devl_internal.h | 4 + net/devlink/netlink.c | 2 +- net/devlink/netlink_gen.c | 49 ++- net/devlink/netlink_gen.h | 8 +- net/devlink/port.c | 3 + net/devlink/resource.c | 366 +++++++++++++++--- .../drivers/net/netdevsim/devlink.sh | 53 ++- 15 files changed, 581 insertions(+), 74 deletions(-) base-commit: 90fcb0f3bc5ab67773b35030af68ed8c6bd83e1c -- 2.44.0
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. 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?
Tue, Mar 03, 2026 at 04:26:40AM +0100, kuba@kernel.org 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 :)
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: >>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.
On Wed, 4 Mar 2026 11:34:13 +0100 Jiri Pirko wrote: > >>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. That's true, the user space must be able to interpret the object identifier. So if we extend the command to add more identifiers we will have to add the bitmask to the dump request, and have the user space tell the kernel which objects it can recognize. I was just saying that we don't have to add such attribute now, maybe leave a comment in a strategic place for our future selves?
Wed, Mar 04, 2026 at 07:15:22PM +0100, kuba@kernel.org wrote: >On Wed, 4 Mar 2026 11:34:13 +0100 Jiri Pirko wrote: >> >>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. > >That's true, the user space must be able to interpret the object >identifier. So if we extend the command to add more identifiers >we will have to add the bitmask to the dump request, and have >the user space tell the kernel which objects it can recognize. >I was just saying that we don't have to add such attribute now, >maybe leave a comment in a strategic place for our future selves? Or, alternatively, we can have per-object dumps as we have for all objects and command right now and leave things simple and straightforward? I mean, I don't really see a benefit of a single dump for more objects :/
On Thu, 5 Mar 2026 08:56:42 +0100 Jiri Pirko wrote: > Wed, Mar 04, 2026 at 07:15:22PM +0100, kuba@kernel.org wrote: > >On Wed, 4 Mar 2026 11:34:13 +0100 Jiri Pirko wrote: > >> 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. > > > >That's true, the user space must be able to interpret the object > >identifier. So if we extend the command to add more identifiers > >we will have to add the bitmask to the dump request, and have > >the user space tell the kernel which objects it can recognize. > >I was just saying that we don't have to add such attribute now, > >maybe leave a comment in a strategic place for our future selves? > > Or, alternatively, we can have per-object dumps as we have for all > objects and command right now and leave things simple and > straightforward? I mean, I don't really see a benefit of a single dump > for more objects :/ What do you mean by straightforward, exactly? User will most likely want to see all resources of a device in a single dump / command. The objects themselves are identical, they only differ by the handle, and yet we'd have two separate commands to access them. It's as if we had separate GETLINK commands in rtnetlink for devices on the PCIe bus vs connected via USB.
Thu, Mar 05, 2026 at 03:37:29PM +0100, kuba@kernel.org wrote: >On Thu, 5 Mar 2026 08:56:42 +0100 Jiri Pirko wrote: >> Wed, Mar 04, 2026 at 07:15:22PM +0100, kuba@kernel.org wrote: >> >On Wed, 4 Mar 2026 11:34:13 +0100 Jiri Pirko wrote: >> >> 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. >> > >> >That's true, the user space must be able to interpret the object >> >identifier. So if we extend the command to add more identifiers >> >we will have to add the bitmask to the dump request, and have >> >the user space tell the kernel which objects it can recognize. >> >I was just saying that we don't have to add such attribute now, >> >maybe leave a comment in a strategic place for our future selves? >> >> Or, alternatively, we can have per-object dumps as we have for all >> objects and command right now and leave things simple and >> straightforward? I mean, I don't really see a benefit of a single dump >> for more objects :/ > >What do you mean by straightforward, exactly? > >User will most likely want to see all resources of a device in a single >dump / command. Hmm. We actually already have this for region and health reporter dumps. Only for params we have that separate. So let's do it for resource too. Thanks! > >The objects themselves are identical, they only differ by the handle, >and yet we'd have two separate commands to access them. > >It's as if we had separate GETLINK commands in rtnetlink for devices on >the PCIe bus vs connected via USB.
On Fri, 6 Mar 2026 13:13:26 +0100 Jiri Pirko wrote: > Thu, Mar 05, 2026 at 03:37:29PM +0100, kuba@kernel.org wrote: > >On Thu, 5 Mar 2026 08:56:42 +0100 Jiri Pirko wrote: > >> Or, alternatively, we can have per-object dumps as we have for all > >> objects and command right now and leave things simple and > >> straightforward? I mean, I don't really see a benefit of a single dump > >> for more objects :/ > > > >What do you mean by straightforward, exactly? > > > >User will most likely want to see all resources of a device in a single > >dump / command. > > Hmm. We actually already have this for region and health reporter dumps. > Only for params we have that separate. > So let's do it for resource too. That's not a good argument, as I said in my first response to the thread: I worry we are mechanically following the design of other commands. https://lore.kernel.org/all/20260302192640.49af074f@kernel.org/
On 06/03/2026 22:03, Jakub Kicinski wrote:
> External email: Use caution opening links or attachments
>
>
> On Fri, 6 Mar 2026 13:13:26 +0100 Jiri Pirko wrote:
>> Thu, Mar 05, 2026 at 03:37:29PM +0100, kuba@kernel.org wrote:
>>> On Thu, 5 Mar 2026 08:56:42 +0100 Jiri Pirko wrote:
>>>> Or, alternatively, we can have per-object dumps as we have for all
>>>> objects and command right now and leave things simple and
>>>> straightforward? I mean, I don't really see a benefit of a single dump
>>>> for more objects :/
>>>
>>> What do you mean by straightforward, exactly?
>>>
>>> User will most likely want to see all resources of a device in a single
>>> dump / command.
>>
>> Hmm. We actually already have this for region and health reporter dumps.
>> Only for params we have that separate.
>> So let's do it for resource too.
>
> That's not a good argument, as I said in my first response to the
> thread:
>
> I worry we are mechanically following the design of other commands.
>
> https://lore.kernel.org/all/20260302192640.49af074f@kernel.org/
>
Hi,
Do you mean that we will register resources per port, but not show with
new devlink port resource show.
Instead, the current devlink resource show dev command will also display
the ports of that device?
For example:
$ devlink resource show pci/0000:03:00.0
pci/0000:03:00.0:
name local_max_SFs size 40 unit entry
pci/0000:03:00.0/196608:
name max_SFs size 20 unit entry
pci/0000:03:00.0/196609:
name max_SFs size 20 unit entry
Or should we keep the current behavior where devlink resource show dev
displays only device-level resources, and only the full dump shows both
devices and their ports?
For example:
$ devlink resource show
pci/0000:03:00.0:
name local_max_SFs size 40 unit entry
pci/0000:03:00.0/196608:
name max_SFs size 20 unit entry
pci/0000:03:00.0/196609:
name max_SFs size 20 unit entry
pci/0000:03:00.1:
name local_max_SFs size 40 unit entry
pci/0000:03:00.1/196608:
name max_SFs size 20 unit entry
pci/0000:03:00.1/196609:
name max_SFs size 20 unit entry
Want to confirm which behavior you meant.
Thanks.
On Sun, 8 Mar 2026 18:03:11 +0200 Or Har-Toov wrote: > Do you mean that we will register resources per port, but not show with > new devlink port resource show. > Instead, the current devlink resource show dev command will also display > the ports of that device? > > For example: > > $ devlink resource show pci/0000:03:00.0 > pci/0000:03:00.0: > name local_max_SFs size 40 unit entry > pci/0000:03:00.0/196608: > name max_SFs size 20 unit entry > pci/0000:03:00.0/196609: > name max_SFs size 20 unit entry > > Or should we keep the current behavior where devlink resource show dev > displays only device-level resources, and only the full dump shows both > devices and their ports? > > For example: > > $ devlink resource show > pci/0000:03:00.0: > name local_max_SFs size 40 unit entry > pci/0000:03:00.0/196608: > name max_SFs size 20 unit entry > pci/0000:03:00.0/196609: > name max_SFs size 20 unit entry > pci/0000:03:00.1: > name local_max_SFs size 40 unit entry > pci/0000:03:00.1/196608: > name max_SFs size 20 unit entry > pci/0000:03:00.1/196609: > name max_SFs size 20 unit entry > > Want to confirm which behavior you meant. No strong preference on the CLI. For the kernel I think specifying the device should not exclude the port resources. Whether port resources are shown or not should be entirely up to the mask attribute. Thinking about this some more after my last reply to Jiri I think we should add that mask attribute to let user decide whether they want only the device resources, port resources or both. This will retain the exact functionality of the series. On the CLI "devlink resource show" should show all resources in the system IMO. How we define the CLI arguments to scope things down I don't have a strong opinion on.
On 09/03/2026 22:33, Jakub Kicinski wrote: > > > On Sun, 8 Mar 2026 18:03:11 +0200 Or Har-Toov wrote: >> Do you mean that we will register resources per port, but not show with >> new devlink port resource show. >> Instead, the current devlink resource show dev command will also display >> the ports of that device? >> >> For example: >> >> $ devlink resource show pci/0000:03:00.0 >> pci/0000:03:00.0: >> name local_max_SFs size 40 unit entry >> pci/0000:03:00.0/196608: >> name max_SFs size 20 unit entry >> pci/0000:03:00.0/196609: >> name max_SFs size 20 unit entry >> >> Or should we keep the current behavior where devlink resource show dev >> displays only device-level resources, and only the full dump shows both >> devices and their ports? >> >> For example: >> >> $ devlink resource show >> pci/0000:03:00.0: >> name local_max_SFs size 40 unit entry >> pci/0000:03:00.0/196608: >> name max_SFs size 20 unit entry >> pci/0000:03:00.0/196609: >> name max_SFs size 20 unit entry >> pci/0000:03:00.1: >> name local_max_SFs size 40 unit entry >> pci/0000:03:00.1/196608: >> name max_SFs size 20 unit entry >> pci/0000:03:00.1/196609: >> name max_SFs size 20 unit entry >> >> Want to confirm which behavior you meant. > > No strong preference on the CLI. For the kernel I think specifying > the device should not exclude the port resources. Whether port > resources are shown or not should be entirely up to the mask attribute. > > Thinking about this some more after my last reply to Jiri I think we > should add that mask attribute to let user decide whether they want > only the device resources, port resources or both. This will retain > the exact functionality of the series. > > On the CLI "devlink resource show" should show all resources in the > system IMO. How we define the CLI arguments to scope things down I don't > have a strong opinion on. So for the dump of all resources it is clear. But I want to make sure I understood the scope/mask part: For the dump-it command: devlink resource show pci/0000:03:00.0: <resource> pci/0000:03:00.0/196608: <port-resource> pci/0000:03:00.0/196609: <port-resource> pci/0000:03:00.1: <resource> pci/0000:03:00.1/262144: <port-resource> devlink resource show scope port pci/0000:03:00.0/196608: <port-resource> pci/0000:03:00.0/196609: <port-resource> pci/0000:03:00.1/262144: <port-resource> devlink resource show scope dev pci/0000:03:00.0: <resource> pci/0000:03:00.1: <resource> 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> The way to get the dev or port scope will be by bitmask in the netlink message of the dump/doit command. Thank you
On Wed, 11 Mar 2026 20:24:08 +0200 Or Har-Toov wrote: > For the dump-it command: > devlink resource show > pci/0000:03:00.0: > <resource> > pci/0000:03:00.0/196608: > <port-resource> > pci/0000:03:00.0/196609: > <port-resource> > pci/0000:03:00.1: > <resource> > pci/0000:03:00.1/262144: > <port-resource> > > devlink resource show scope port > pci/0000:03:00.0/196608: > <port-resource> > pci/0000:03:00.0/196609: > <port-resource> > pci/0000:03:00.1/262144: > <port-resource> > > devlink resource show scope dev > pci/0000:03:00.0: > <resource> > pci/0000:03:00.1: > <resource> LGTM > 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.
Wed, Mar 11, 2026 at 10:51:26PM +0100, kuba@kernel.org wrote: >On Wed, 11 Mar 2026 20:24:08 +0200 Or Har-Toov wrote: >> For the dump-it command: >> devlink resource show >> pci/0000:03:00.0: >> <resource> >> pci/0000:03:00.0/196608: >> <port-resource> >> pci/0000:03:00.0/196609: >> <port-resource> >> pci/0000:03:00.1: >> <resource> >> pci/0000:03:00.1/262144: >> <port-resource> >> >> devlink resource show scope port >> pci/0000:03:00.0/196608: >> <port-resource> >> pci/0000:03:00.0/196609: >> <port-resource> >> pci/0000:03:00.1/262144: >> <port-resource> >> >> 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? > >> 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). Let's make this simple.
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? > >> 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 :)
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: >> >> 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.
On Thu, 12 Mar 2026 15:29:53 +0100 Jiri Pirko wrote: > >> 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? That's a judgment call - either we confuse users but two commands behaving differently, or we confuse users with devlink $thing not dumping all instances of the $thing. Especially that drivers often retroactively move $things from device scope to port scope :(
© 2016 - 2026 Red Hat, Inc.