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

[Jiri Pirko]

Wed, Feb 04, 2026 at 04:01:05AM +0100, kuba@xxxxxxxxxx wrote:
>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.

What's the backing device / handle (busname/devname)? Best would be to
draw a picture, as always :)


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

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?


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