Re: [PATCH net-next V4 02/14] documentation: networking: add shared devlink documentation

[Jiri Pirko]

Mon, Dec 01, 2025 at 10:49:54PM +0100, kuba@xxxxxxxxxx wrote:
>On Mon, 1 Dec 2025 11:50:08 +0100 Jiri Pirko wrote:
>> >> I'm not sure I follow. If there is only one PF bound, there is 1:1
>> >> relationship. Depends on how many PFs of the same ASIC you have.  
>> >
>> >I'm talking about multi-PF devices. mlx5 supports multi-PF setup for
>> >NUMA locality IIUC. In such configurations per-PF parameters can be
>> >configured on PCI PF ports.  
>> 
>> Correct. IFAIK there is one PF devlink instance per NUMA node.
>
>You say "correct" and then disagree with what I'm saying. I said
>ports because a port is a devlink object. Not a devlink instance.

Okay, you mean devlink_port. You would like to see NUMA node leg as
devlink_port? Having troubles to undestand exactly what you mean, lot of
guessing on my side. Probably I'm slow, sorry.

But there is a PCI device per NUMA node leg. Not sure how to model it.
Devink instances have 1:1 relationship with bus devices.

Care to draw a picture perhaps?


>
>> The shared instance on top would make sense to me. That was one of
>> motivations to introduce it. Then this shared instance would hold
>> netdev, vf representors etc.
>
>I don't understand what the shared instance is representing and how
>user is expect to find their way thru the maze of devlink instanced,
>for real bus, aux bus, and now shared instanced.

Well, I tried to desrtibe it in the documentation path, Not sure what is
not clear :/

Nested devlinks expose the connections between devlink instances.


>
>> >> Well, the mutex protect the list of instances which are managed in the
>> >> driver. If you want to move the mutex, I don't see how to do it without
>> >> moving all the code related to shared devlink instances, including faux
>> >> probe etc. Is that what you suggest?  
>> >
>> >Multiple ways you can solve it, but drivers should have to duplicate
>> >all the instance management and locking. BTW please don't use guard().  
>> 
>> I'm having troubles to undestand what you say, sorry :/ Do you prefer to
>> move the code from driver to devlink core or not?
>
>I missed a "not".. drivers should _not_ have to duplicate, sorry.

Okay, that means "yes".


>
>> Regarding guard(), sure. I wonder how much more time it's gonna take
>> since this resistentance fades out :)
>
>guard() locks code instead of data accesses. We used to make fun of
>Java in this community, you know.

Time changes :)