netdev - Re: [PATCH net-next v3 2/3] devlink: add function unique identifier to devlink dev info

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 for Android: free password hash cracker in your pocket

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

Message-ID: <u55em7inbrhkstex6fwvjr3tu5dnvmtsu77sgspwqxo5j4p6ii@dwfzd7wawrck>
Date: Tue, 29 Apr 2025 09:16:43 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com, 
	pabeni@...hat.com, tariqt@...dia.com, andrew+netdev@...n.ch, horms@...nel.org, 
	donald.hunter@...il.com, kalesh-anakkur.purayil@...adcom.com
Subject: Re: [PATCH net-next v3 2/3] devlink: add function unique identifier
 to devlink dev info

Mon, Apr 28, 2025 at 08:12:52PM +0200, kuba@...nel.org wrote:
>On Mon, 28 Apr 2025 18:28:24 +0200 Jiri Pirko wrote:
>> >You just need to find a better place to expose the client side.  
>> 
>> Okay. Why exactly you find it wrong to put it under devlink dev info?
>> I mean, to me it is perfect fit. It is basically another serial number,
>> uniqueue identification of devlink device.
>> 
>> If other place is better fit, I don't see it.
>
>devlink instance should represent the device, not a PF / port;
>and then having the attribute on the instance does not fit
>an eswitch controller with 2 PFs connected.

Why do you say so? In reality, devlink device is created per PF/VF/SF.
It actually makes sense as it is always based-on/backed-by parcticular
pci function or other device with address (like i2c).

The faux parent in the RFC I linked to is the per-device/asic instance
you are probably looking for. There is no real pci function backing it.
It is a parent of multiple PF devlink instances.

>
>> Do you have some ideas?
>
>Either subsystem specific (like a netdev attr) or not subsystem

I don't see how subsystem specific would make sense here, as the
function uuid is subsystem-agnostic.

>specific (bus dev attr, so PCI). Forcing every endpoint to expose
>a devlink instance just for one attribute is too much of a hack.

Wait, that's a misunderstanding. There is no forcing. Any driver has a
benevolency to either instantiate devlink instance for PF/VF/SF,
according to its needs, or not.

In mlx5, there is a need to do that. So if one has a need to expose
serial number of function id over devlink, he instantiates devlink
instance. What's even remotely hacky about that?