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:

quoted

Wed, Feb 04, 2026 at 04:01:05AM +0100, kuba@kernel.org wrote:

quoted

On Tue, 3 Feb 2026 10:18:22 +0100 Jiri Pirko wrote:  

quoted

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?

quoted

quoted

quoted

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/ (local)
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.

quoted

quoted

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?