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:

quoted

Tue, Feb 03, 2026 at 04:40:23AM +0100, kuba@kernel.org wrote:

quoted

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

quoted

quoted

quoted

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

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?

quoted

quoted

quoted

+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!