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

[Jakub Kicinski]

On Tue, 3 Feb 2026 10:18:22 +0100 Jiri Pirko wrote:
> Tue, Feb 03, 2026 at 04:40:23AM +0100, kuba@xxxxxxxxxx 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.