From: Jiri Pirko <jiri@nvidia.com>

Document shared devlink instances for multiple PFs on the same chip.

Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
 .../networking/devlink/devlink-shared.rst     | 95 +++++++++++++++++++
 Documentation/networking/devlink/index.rst    |  1 +
 2 files changed, 96 insertions(+)
 create mode 100644 Documentation/networking/devlink/devlink-shared.rst

diff --git a/Documentation/networking/devlink/devlink-shared.rst b/Documentation/networking/devlink/devlink-shared.rst
new file mode 100644
index 000000000000..74655dc671bc
--- /dev/null
+++ b/Documentation/networking/devlink/devlink-shared.rst
@@ -0,0 +1,95 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============================
+Devlink Shared Instances
+============================
+
+Overview
+========
+
+Shared devlink instances allow multiple physical functions (PFs) on the same
+chip to share an additional devlink instance for chip-wide operations. This
+is implemented within individual drivers alongside the individual PF devlink
+instances, not replacing them.
+
+Multiple PFs may reside on the same physical chip, running a single firmware.
+Some of the resources and configurations may be shared among these PFs. The
+shared devlink instance provides an object to pin configuration knobs on.
+
+The shared devlink instance is backed by a faux device and provides a common
+interface for operations that affect the entire chip rather than individual PFs.
+A faux device is used as a backing device for the 'entire chip' since there's no
+additional real device instantiated by hardware besides the PF devices.
+
+Implementation
+==============
+
+Architecture
+------------
+
+The implementation uses:
+
+* **Faux device**: Virtual device backing the shared devlink instance
+* **Chip identification**: PFs are grouped by chip using a driver-specific identifier
+* **Shared instance management**: Global list of shared instances with reference counting
+
+API Functions
+-------------
+
+The following functions are provided for managing shared devlink instances:
+
+* ``devlink_shd_get()``: Get or create a shared devlink instance identified by a string ID
+* ``devlink_shd_put()``: Release a reference on a shared devlink instance
+* ``devlink_shd_get_priv()``: Get private data from shared devlink instance
+
+Initialization Flow
+-------------------
+
+1. **PF calls shared devlink init** during driver probe
+2. **Chip identification** using driver-specific method to determine device identity
+3. **Get or create shared instance** using ``devlink_shd_get()``:
+
+   * The function looks up existing instance by identifier
+   * If none exists, creates new instance:
+     - Creates faux device with chip identifier as name
+     - Allocates and registers devlink instance
+     - Adds to global shared instances list
+     - Increments reference count
+
+4. **Set nested devlink instance** for the PF devlink instance using
+   ``devl_nested_devlink_set()`` before registering the PF devlink instance
+
+Cleanup Flow
+------------
+
+1. **Cleanup** when PF is removed
+2. **Call** ``devlink_shd_put()`` to release reference (decrements reference count)
+3. **Shared instance is automatically destroyed** when the last PF removes (device list becomes empty)
+
+Chip Identification
+-------------------
+
+PFs belonging to the same chip are identified using a driver-specific method.
+The driver is free to choose any identifier that is suitable for determining
+whether two PFs are part of the same device. Examples include:
+
+* **PCI VPD serial numbers**: Extract from PCI VPD
+* **Device tree properties**: Read chip identifier from device tree
+* **Other hardware-specific identifiers**: Any unique identifier that groups PFs by chip
+
+Locking
+-------
+
+A global mutex (``shd_mutex``) protects the shared instances list during
+registration/deregistration.
+
+Similarly to other nested devlink instance relationships, devlink lock of
+the shared instance should be always taken after the devlink lock of PF.
+
+Reference Counting
+------------------
+
+Each shared devlink instance maintains a reference count (``refcount_t refcount``).
+The reference count is incremented when ``devlink_shd_get()`` is called and
+decremented when ``devlink_shd_put()`` is called. When the reference count
+reaches zero, the shared instance is automatically destroyed.
diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst
index 35b12a2bfeba..f7ba7dcf477d 100644
--- a/Documentation/networking/devlink/index.rst
+++ b/Documentation/networking/devlink/index.rst
@@ -68,6 +68,7 @@ general.
    devlink-resource
    devlink-selftests
    devlink-trap
+   devlink-shared
 
 Driver-specific documentation
 -----------------------------
-- 
2.44.0

On Wed, 28 Jan 2026 13:25:31 +0200 Tariq Toukan wrote:
> From: Jiri Pirko <jiri@nvidia.com>
> 
> Document shared devlink instances for multiple PFs on the same chip.

> diff --git a/Documentation/networking/devlink/devlink-shared.rst b/Documentation/networking/devlink/devlink-shared.rst
> new file mode 100644
> index 000000000000..74655dc671bc
> --- /dev/null
> +++ b/Documentation/networking/devlink/devlink-shared.rst
> @@ -0,0 +1,95 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +============================
> +Devlink Shared Instances
> +============================

Shouldn't the length of the ==== lines match the title length?

> +Overview
> +========
> +
> +Shared devlink instances allow multiple physical functions (PFs) on the same
> +chip to share an additional devlink instance for chip-wide operations. This
> +is implemented within individual drivers alongside the individual PF devlink
> +instances, not replacing them.
> +
> +Multiple PFs may reside on the same physical chip, running a single firmware.
> +Some of the resources and configurations may be shared among these PFs. The
> +shared devlink instance provides an object to pin configuration knobs on.
> +
> +The shared devlink instance is backed by a faux device and provides a common
> +interface for operations that affect the entire chip rather than individual PFs.
> +A faux device is used as a backing device for the 'entire chip' since there's no
> +additional real device instantiated by hardware besides the PF devices.

There needs to be a note here clearly stating the the use of "shared
devlink instace" is a hack for legacy drivers, and new drivers should
have a single devlink instance for the entire device. The fact that
single instance is always preferred, and *more correct* must be made
very clear to the reader. Ideally the single instance multiple function
implementation would leverage the infra added here for collecting the
functions, however.

> +Implementation
> +==============
> +
> +Architecture
> +------------
> +
> +The implementation uses:
> +
> +* **Faux device**: Virtual device backing the shared devlink instance

"backing"? It isn't backing anything, its just another hack because we
made the mistake of tying devlink instances to $bus/$device as an id.
Now we need a fake device to have an identifier.

> +* **Chip identification**: PFs are grouped by chip using a driver-specific identifier
> +* **Shared instance management**: Global list of shared instances with reference counting
> +
> +API Functions
> +-------------
> +
> +The following functions are provided for managing shared devlink instances:
> +
> +* ``devlink_shd_get()``: Get or create a shared devlink instance identified by a string ID
> +* ``devlink_shd_put()``: Release a reference on a shared devlink instance
> +* ``devlink_shd_get_priv()``: Get private data from shared devlink instance
> +
> +Initialization Flow
> +-------------------
> +
> +1. **PF calls shared devlink init** during driver probe
> +2. **Chip identification** using driver-specific method to determine device identity

This isn't very clear.

> +3. **Get or create shared instance** using ``devlink_shd_get()``:

Just "Call ``devlink_shd_get()`` with the identifier constructed in
step 2" (?) and then have the points below explain that it gets or
recreates

> +   * The function looks up existing instance by identifier
> +   * If none exists, creates new instance:
> +     - Creates faux device with chip identifier as name
> +     - Allocates and registers devlink instance
> +     - Adds to global shared instances list
> +     - Increments reference count
> +
> +4. **Set nested devlink instance** for the PF devlink instance using
> +   ``devl_nested_devlink_set()`` before registering the PF devlink instance
> +
> +Cleanup Flow
> +------------
> +
> +1. **Cleanup** when PF is removed

"``.remove()`` callback for a PCIe device is called"

> +2. **Call** ``devlink_shd_put()`` to release reference (decrements reference count)
> +3. **Shared instance is automatically destroyed** when the last PF removes (device list becomes empty)
> +
> +Chip Identification
> +-------------------
> +
> +PFs belonging to the same chip are identified using a driver-specific method.
> +The driver is free to choose any identifier that is suitable for determining
> +whether two PFs are part of the same device. Examples include:
> +
> +* **PCI VPD serial numbers**: Extract from PCI VPD
> +* **Device tree properties**: Read chip identifier from device tree
> +* **Other hardware-specific identifiers**: Any unique identifier that groups PFs by chip
> +
> +Locking
> +-------
> +
> +A global mutex (``shd_mutex``) protects the shared instances list during
> +registration/deregistration.
> +
> +Similarly to other nested devlink instance relationships, devlink lock of
> +the shared instance should be always taken after the devlink lock of PF.

of an instance, not a PF

> +
> +Reference Counting
> +------------------
> +
> +Each shared devlink instance maintains a reference count (``refcount_t refcount``).
> +The reference count is incremented when ``devlink_shd_get()`` is called and
> +decremented when ``devlink_shd_put()`` is called. When the reference count
> +reaches zero, the shared instance is automatically destroyed.

I think AI went too far with the text generation here, this is very
obvious from the previous sections.
-- 
pw-bot: cr

Tue, Feb 03, 2026 at 04:40:23AM +0100, kuba@kernel.org wrote:
>On Wed, 28 Jan 2026 13:25:31 +0200 Tariq Toukan wrote:
>> From: Jiri Pirko <jiri@nvidia.com>
>> 
>> Document shared devlink instances for multiple PFs on the same chip.
>
>> diff --git a/Documentation/networking/devlink/devlink-shared.rst b/Documentation/networking/devlink/devlink-shared.rst
>> new file mode 100644
>> index 000000000000..74655dc671bc
>> --- /dev/null
>> +++ b/Documentation/networking/devlink/devlink-shared.rst
>> @@ -0,0 +1,95 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +============================
>> +Devlink Shared Instances
>> +============================
>
>Shouldn't the length of the ==== lines match the title length?
>
>> +Overview
>> +========
>> +
>> +Shared devlink instances allow multiple physical functions (PFs) on the same
>> +chip to share an additional devlink instance for chip-wide operations. This
>> +is implemented within individual drivers alongside the individual PF devlink
>> +instances, not replacing them.
>> +
>> +Multiple PFs may reside on the same physical chip, running a single firmware.
>> +Some of the resources and configurations may be shared among these PFs. The
>> +shared devlink instance provides an object to pin configuration knobs on.
>> +
>> +The shared devlink instance is backed by a faux device and provides a common
>> +interface for operations that affect the entire chip rather than individual PFs.
>> +A faux device is used as a backing device for the 'entire chip' since there's no
>> +additional real device instantiated by hardware besides the PF devices.
>
>There needs to be a note here clearly stating the the use of "shared
>devlink instace" is a hack for legacy drivers, and new drivers should
>have a single devlink instance for the entire device. The fact that
>single instance is always preferred, and *more correct* must be made
>very clear to the reader. Ideally the single instance multiple function
>implementation would leverage the infra added here for collecting the
>functions, however.

How exactly you can have a single devlink instance for multiple PFs of a
same device? I don't really understand how that could work, considering
dynamic binds/unbinds of the PFs within single host and/or multiple VMs
passing PFs to.


>
>> +Implementation
>> +==============
>> +
>> +Architecture
>> +------------
>> +
>> +The implementation uses:
>> +
>> +* **Faux device**: Virtual device backing the shared devlink instance
>
>"backing"? It isn't backing anything, its just another hack because we
>made the mistake of tying devlink instances to $bus/$device as an id.
>Now we need a fake device to have an identifier.

Okay. I originally wanted to use an id, similar to what we have in
the dpll. However I was forced by community to tie the instance to
bus/device. It is how it is, any idea how to relax this bond?



>
>> +* **Chip identification**: PFs are grouped by chip using a driver-specific identifier
>> +* **Shared instance management**: Global list of shared instances with reference counting
>> +
>> +API Functions
>> +-------------
>> +
>> +The following functions are provided for managing shared devlink instances:
>> +
>> +* ``devlink_shd_get()``: Get or create a shared devlink instance identified by a string ID
>> +* ``devlink_shd_put()``: Release a reference on a shared devlink instance
>> +* ``devlink_shd_get_priv()``: Get private data from shared devlink instance
>> +
>> +Initialization Flow
>> +-------------------
>> +
>> +1. **PF calls shared devlink init** during driver probe
>> +2. **Chip identification** using driver-specific method to determine device identity
>
>This isn't very clear.

Hmm, any suggestion to make it cleaner?


>
>> +3. **Get or create shared instance** using ``devlink_shd_get()``:
>
>Just "Call ``devlink_shd_get()`` with the identifier constructed in
>step 2" (?) and then have the points below explain that it gets or
>recreates

Okay.


>
>> +   * The function looks up existing instance by identifier
>> +   * If none exists, creates new instance:
>> +     - Creates faux device with chip identifier as name
>> +     - Allocates and registers devlink instance
>> +     - Adds to global shared instances list
>> +     - Increments reference count
>> +
>> +4. **Set nested devlink instance** for the PF devlink instance using
>> +   ``devl_nested_devlink_set()`` before registering the PF devlink instance
>> +
>> +Cleanup Flow
>> +------------
>> +
>> +1. **Cleanup** when PF is removed
>
>"``.remove()`` callback for a PCIe device is called"
>
>> +2. **Call** ``devlink_shd_put()`` to release reference (decrements reference count)
>> +3. **Shared instance is automatically destroyed** when the last PF removes (device list becomes empty)
>> +
>> +Chip Identification
>> +-------------------
>> +
>> +PFs belonging to the same chip are identified using a driver-specific method.
>> +The driver is free to choose any identifier that is suitable for determining
>> +whether two PFs are part of the same device. Examples include:
>> +
>> +* **PCI VPD serial numbers**: Extract from PCI VPD
>> +* **Device tree properties**: Read chip identifier from device tree
>> +* **Other hardware-specific identifiers**: Any unique identifier that groups PFs by chip
>> +
>> +Locking
>> +-------
>> +
>> +A global mutex (``shd_mutex``) protects the shared instances list during
>> +registration/deregistration.
>> +
>> +Similarly to other nested devlink instance relationships, devlink lock of
>> +the shared instance should be always taken after the devlink lock of PF.
>
>of an instance, not a PF

lock of PF devlink instance. I think that is what the text says, no?


>
>> +
>> +Reference Counting
>> +------------------
>> +
>> +Each shared devlink instance maintains a reference count (``refcount_t refcount``).
>> +The reference count is incremented when ``devlink_shd_get()`` is called and
>> +decremented when ``devlink_shd_put()`` is called. When the reference count
>> +reaches zero, the shared instance is automatically destroyed.
>
>I think AI went too far with the text generation here, this is very
>obvious from the previous sections.
>-- 
>pw-bot: cr

On Tue, 3 Feb 2026 10:18:22 +0100 Jiri Pirko wrote:
> Tue, Feb 03, 2026 at 04:40:23AM +0100, kuba@kernel.org wrote:
> >There needs to be a note here clearly stating the the use of "shared
> >devlink instace" is a hack for legacy drivers, and new drivers should
> >have a single devlink instance for the entire device. The fact that
> >single instance is always preferred, and *more correct* must be made
> >very clear to the reader. Ideally the single instance multiple function
> >implementation would leverage the infra added here for collecting the
> >functions, however.  
> 
> How exactly you can have a single devlink instance for multiple PFs of a
> same device? I don't really understand how that could work, considering
> dynamic binds/unbinds of the PFs within single host and/or multiple VMs
> passing PFs to.

The same way you currently gather up the devlink instances to create
the shared instance.

> >> +The implementation uses:
> >> +
> >> +* **Faux device**: Virtual device backing the shared devlink instance  
> >
> >"backing"? It isn't backing anything, its just another hack because we
> >made the mistake of tying devlink instances to $bus/$device as an id.
> >Now we need a fake device to have an identifier.  
> 
> Okay. I originally wanted to use an id, similar to what we have in
> the dpll. However I was forced by community to tie the instance to
> bus/device. It is how it is, any idea how to relax this bond?

Interesting! I was curious to research how we ended up here, found this:
https://lore.kernel.org/netdev/20160225225803.GA2191@nanopsycho.orion/
My reading is that Hannes was arguing against the _NAME attribute but
both _NAME and _INDEX were deleted? I think there's nothing wrong with
an index.

FWIW using devlink day to day, the bus/device is not at all useful as
an identifier. Most of code touching devlink at Meta either matches
on devlink dev info or assumes there's one instance on the system.

> >> +Similarly to other nested devlink instance relationships, devlink lock of
> >> +the shared instance should be always taken after the devlink lock of PF.  
> >
> >of an instance, not a PF  
> 
> lock of PF devlink instance. I think that is what the text says, no?

Sorry, I was trying to flag that using PF is not necessary great cause
we may support this on other functions in the future.

Wed, Feb 04, 2026 at 04:01:05AM +0100, kuba@kernel.org wrote:
>On Tue, 3 Feb 2026 10:18:22 +0100 Jiri Pirko wrote:
>> Tue, Feb 03, 2026 at 04:40:23AM +0100, kuba@kernel.org wrote:
>> >There needs to be a note here clearly stating the the use of "shared
>> >devlink instace" is a hack for legacy drivers, and new drivers should
>> >have a single devlink instance for the entire device. The fact that
>> >single instance is always preferred, and *more correct* must be made
>> >very clear to the reader. Ideally the single instance multiple function
>> >implementation would leverage the infra added here for collecting the
>> >functions, however.  
>> 
>> How exactly you can have a single devlink instance for multiple PFs of a
>> same device? I don't really understand how that could work, considering
>> dynamic binds/unbinds of the PFs within single host and/or multiple VMs
>> passing PFs to.
>
>The same way you currently gather up the devlink instances to create
>the shared instance.

What's the backing device / handle (busname/devname)? Best would be to
draw a picture, as always :)


>
>> >> +The implementation uses:
>> >> +
>> >> +* **Faux device**: Virtual device backing the shared devlink instance  
>> >
>> >"backing"? It isn't backing anything, its just another hack because we
>> >made the mistake of tying devlink instances to $bus/$device as an id.
>> >Now we need a fake device to have an identifier.  
>> 
>> Okay. I originally wanted to use an id, similar to what we have in
>> the dpll. However I was forced by community to tie the instance to
>> bus/device. It is how it is, any idea how to relax this bond?
>
>Interesting! I was curious to research how we ended up here, found this:
>https://lore.kernel.org/netdev/20160225225803.GA2191@nanopsycho.orion/
>My reading is that Hannes was arguing against the _NAME attribute but
>both _NAME and _INDEX were deleted? I think there's nothing wrong with
>an index.

He argues for "stable topology indentifiers", which randomly assigned
index is not.


>
>FWIW using devlink day to day, the bus/device is not at all useful as
>an identifier. Most of code touching devlink at Meta either matches
>on devlink dev info or assumes there's one instance on the system.

Okay, what's your suggestion going foreward then?


>
>> >> +Similarly to other nested devlink instance relationships, devlink lock of
>> >> +the shared instance should be always taken after the devlink lock of PF.  
>> >
>> >of an instance, not a PF  
>> 
>> lock of PF devlink instance. I think that is what the text says, no?
>
>Sorry, I was trying to flag that using PF is not necessary great cause
>we may support this on other functions in the future.

You are right, will fix this.

Thanks!

On Wed, 4 Feb 2026 08:12:00 +0100 Jiri Pirko wrote:
> Wed, Feb 04, 2026 at 04:01:05AM +0100, kuba@kernel.org wrote:
> >On Tue, 3 Feb 2026 10:18:22 +0100 Jiri Pirko wrote:  
> >> How exactly you can have a single devlink instance for multiple PFs of a
> >> same device? I don't really understand how that could work, considering
> >> dynamic binds/unbinds of the PFs within single host and/or multiple VMs
> >> passing PFs to.  
> >
> >The same way you currently gather up the devlink instances to create
> >the shared instance.  
> 
> What's the backing device / handle (busname/devname)? Best would be to
> draw a picture, as always :)

Either the bus/dev that shows up first or we go back to index.
(My main point being that the single instance is strictly better
than shared, ie. no problem exists in single instance multi func
which does not exist in multi instance + extra instance multi func.
But some problems do exist in multi instance which do not in single
like the locking)

> >> Okay. I originally wanted to use an id, similar to what we have in
> >> the dpll. However I was forced by community to tie the instance to
> >> bus/device. It is how it is, any idea how to relax this bond?  
> >
> >Interesting! I was curious to research how we ended up here, found this:
> >https://lore.kernel.org/netdev/20160225225803.GA2191@nanopsycho.orion/
> >My reading is that Hannes was arguing against the _NAME attribute but
> >both _NAME and _INDEX were deleted? I think there's nothing wrong with
> >an index.  
> 
> He argues for "stable topology indentifiers", which randomly assigned
> index is not.

Agreed, I love me a stable identifier myself! :) That does not mean 
we can't have ID _as well_ as the identifiers. Which lets us add
more stable identifiers and/or making some optional.

I think I was trying to sell you on "more stable identifiers" 
as a alternative to ALT_NAMEs for netdevs at some point ;)
Maybe I'm projecting that conversation onto what Hannes said.

> >FWIW using devlink day to day, the bus/device is not at all useful as
> >an identifier. Most of code touching devlink at Meta either matches
> >on devlink dev info or assumes there's one instance on the system.  
> 
> Okay, what's your suggestion going foreward then?

Add the ID back, make bus/dev optional, forgo the faux dev?
Would that work? Would exiting CLI become very unhappy? :S

Thu, Feb 05, 2026 at 03:02:56AM +0100, kuba@kernel.org wrote:
>On Wed, 4 Feb 2026 08:12:00 +0100 Jiri Pirko wrote:
>> Wed, Feb 04, 2026 at 04:01:05AM +0100, kuba@kernel.org wrote:
>> >On Tue, 3 Feb 2026 10:18:22 +0100 Jiri Pirko wrote:  
>> >> How exactly you can have a single devlink instance for multiple PFs of a
>> >> same device? I don't really understand how that could work, considering
>> >> dynamic binds/unbinds of the PFs within single host and/or multiple VMs
>> >> passing PFs to.  
>> >
>> >The same way you currently gather up the devlink instances to create
>> >the shared instance.  
>> 
>> What's the backing device / handle (busname/devname)? Best would be to
>> draw a picture, as always :)
>
>Either the bus/dev that shows up first or we go back to index.

That may be tricky in case you bind/unbind the PFs randomly. You may and
up with devlink handle of PF1 with only member PF2. Confusing at least.
You need to expose the members to the user anyway somehow. That is
exactly the list of nested instances these patchset is adding.


>(My main point being that the single instance is strictly better
>than shared, ie. no problem exists in single instance multi func
>which does not exist in multi instance + extra instance multi func.
>But some problems do exist in multi instance which do not in single
>like the locking)

I think that my shared and your shared are basically the same as far as
the nested PF instances are not really used for anything except the
modelling purposes. That should be up to the driver how he wants to play
it, shouldn't it?


>
>> >> Okay. I originally wanted to use an id, similar to what we have in
>> >> the dpll. However I was forced by community to tie the instance to
>> >> bus/device. It is how it is, any idea how to relax this bond?  
>> >
>> >Interesting! I was curious to research how we ended up here, found this:
>> >https://lore.kernel.org/netdev/20160225225803.GA2191@nanopsycho.orion/
>> >My reading is that Hannes was arguing against the _NAME attribute but
>> >both _NAME and _INDEX were deleted? I think there's nothing wrong with
>> >an index.  
>> 
>> He argues for "stable topology indentifiers", which randomly assigned
>> index is not.
>
>Agreed, I love me a stable identifier myself! :) That does not mean 
>we can't have ID _as well_ as the identifiers. Which lets us add
>more stable identifiers and/or making some optional.

Got it.

>
>I think I was trying to sell you on "more stable identifiers" 
>as a alternative to ALT_NAMEs for netdevs at some point ;)

I don't recall that. Anyway, everyone loves ALT_NAMEs at this point :)



>Maybe I'm projecting that conversation onto what Hannes said.
>
>> >FWIW using devlink day to day, the bus/device is not at all useful as
>> >an identifier. Most of code touching devlink at Meta either matches
>> >on devlink dev info or assumes there's one instance on the system.  
>> 
>> Okay, what's your suggestion going foreward then?
>
>Add the ID back, make bus/dev optional, forgo the faux dev?
>Would that work? Would exiting CLI become very unhappy? :S

Ha, that would break so many things, everything is based on
bus/dev on UAPI level :/

I was thinking about having some sort of *special-bus-name* for indexes,
like:

none/1
none/2
or
devlink_id/1
devlink_id/2
or something like that.

But it would be either that or original bus/dev, not both :/

Perhaps we can add ID attr as optional/alternative handle? Then legacy
userspace can use existing bus/dev handle and new can use the ID attr?
Then the example output would look something like:

$ devlink dev
pci/0000:08:00.0: id 1
  nested_devlink:
    auxiliary/mlx5_core.eth.0
devlink_id/2: id 2
  nested_devlink:
    pci/0000:08:00.0
    pci/0000:08:00.1
auxiliary/mlx5_core.eth.0: id 3
pci/0000:08:00.1: id 4
  nested_devlink:
    auxiliary/mlx5_core.eth.1
auxiliary/mlx5_core.eth.1: id 5

Makes sense?

On Fri, 6 Feb 2026 11:52:21 +0100 Jiri Pirko wrote:
> Thu, Feb 05, 2026 at 03:02:56AM +0100, kuba@kernel.org wrote:
> >On Wed, 4 Feb 2026 08:12:00 +0100 Jiri Pirko wrote:  
> >> What's the backing device / handle (busname/devname)? Best would be to
> >> draw a picture, as always :)  
> >
> >Either the bus/dev that shows up first or we go back to index.  
> 
> That may be tricky in case you bind/unbind the PFs randomly. You may and
> up with devlink handle of PF1 with only member PF2. Confusing at least.
> You need to expose the members to the user anyway somehow. That is
> exactly the list of nested instances these patchset is adding.

Yes, simpler setup would likely be to have one function designated 
as "main". This could get fairly complicated, OTOH most current use
cases are fairly rigid, with the function config being per device SKU.
From uAPI perspective having the list of currently present functions
and ports should be flexible for current and future use cases.

> >(My main point being that the single instance is strictly better
> >than shared, ie. no problem exists in single instance multi func
> >which does not exist in multi instance + extra instance multi func.
> >But some problems do exist in multi instance which do not in single
> >like the locking)  
> 
> I think that my shared and your shared are basically the same as far as
> the nested PF instances are not really used for anything except the
> modelling purposes. That should be up to the driver how he wants to play
> it, shouldn't it?

Man, seeing the locking shenanigans that the driver developers end up
doing just in the last two weeks makes me question the "leave it to 
the driver" attitude. I'd much rather have code that works than code
that is adaptive to multiple levels of incompetence.

> >I think I was trying to sell you on "more stable identifiers" 
> >as a alternative to ALT_NAMEs for netdevs at some point ;)  
> 
> I don't recall that. Anyway, everyone loves ALT_NAMEs at this point :)

:)

> >> Okay, what's your suggestion going foreward then?  
> >
> >Add the ID back, make bus/dev optional, forgo the faux dev?
> >Would that work? Would exiting CLI become very unhappy? :S  
> 
> Ha, that would break so many things, everything is based on
> bus/dev on UAPI level :/
> 
> I was thinking about having some sort of *special-bus-name* for indexes,
> like:
> 
> none/1
> none/2
> or
> devlink_id/1
> devlink_id/2
> or something like that.
> 
> But it would be either that or original bus/dev, not both :/
> 
> Perhaps we can add ID attr as optional/alternative handle? Then legacy
> userspace can use existing bus/dev handle and new can use the ID attr?
> Then the example output would look something like:
> 
> $ devlink dev
> pci/0000:08:00.0: id 1
>   nested_devlink:
>     auxiliary/mlx5_core.eth.0
> devlink_id/2: id 2
>   nested_devlink:
>     pci/0000:08:00.0
>     pci/0000:08:00.1
> auxiliary/mlx5_core.eth.0: id 3
> pci/0000:08:00.1: id 4
>   nested_devlink:
>     auxiliary/mlx5_core.eth.1
> auxiliary/mlx5_core.eth.1: id 5
> 
> Makes sense?

Yup, seems reasonable.

Alternatively we could add a socket or request flag to dumps that
indicates that user space is aware that some instances will not
have the bus/dev identifier?