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:

quoted

On Wed, 4 Feb 2026 08:12:00 +0100 Jiri Pirko wrote:  

quoted

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.

quoted

(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.

quoted

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 :)

:)

quoted

quoted

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?