Mon, Dec 01, 2025 at 10:49:54PM +0100, kuba@kernel.org wrote:

On Mon, 1 Dec 2025 11:50:08 +0100 Jiri Pirko wrote:

quoted

quoted

quoted

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?

quoted

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.

quoted

quoted

quoted

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

quoted

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