Re: [PATCH net-next V7 01/14] documentation: networking: add shared devlink documentation

[Jakub Kicinski <kuba@kernel.org>]

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?