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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2lnqrb3fu7dukdkgfculj53q2vwb36nrz5copjfg3khlqnbmix@jbfmhnks7svq>
Date: Tue, 2 Dec 2025 08:43:49 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Tariq Toukan <tariqt@...dia.com>, Eric Dumazet <edumazet@...gle.com>, 
	Paolo Abeni <pabeni@...hat.com>, Andrew Lunn <andrew+netdev@...n.ch>, 
	"David S. Miller" <davem@...emloft.net>, Donald Hunter <donald.hunter@...il.com>, 
	Jonathan Corbet <corbet@....net>, Saeed Mahameed <saeedm@...dia.com>, 
	Leon Romanovsky <leon@...nel.org>, Mark Bloch <mbloch@...dia.com>, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, linux-rdma@...r.kernel.org, 
	Gal Pressman <gal@...dia.com>, Moshe Shemesh <moshe@...dia.com>, 
	Carolina Jubran <cjubran@...dia.com>, Cosmin Ratiu <cratiu@...dia.com>, Jiri Pirko <jiri@...dia.com>, 
	Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH net-next V4 02/14] documentation: networking: add shared
 devlink documentation

Mon, Dec 01, 2025 at 10:49:54PM +0100, kuba@...nel.org 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 :)