netdev - Re: [RFC net-next 0/5] devlink: Add unique identifier to devlink port function

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: <95888476-26e8-425b-b6ae-c2576125f484@nvidia.com>
Date: Mon, 28 Apr 2025 15:11:04 +0300
From: Moshe Shemesh <moshe@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, "Eric
 Dumazet" <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
	<horms@...nel.org>, Donald Hunter <donald.hunter@...il.com>, Jiri Pirko
	<jiri@...nulli.us>, Jonathan Corbet <corbet@....net>, Andrew Lunn
	<andrew+netdev@...n.ch>, Tariq Toukan <tariqt@...dia.com>, Saeed Mahameed
	<saeedm@...dia.com>, Leon Romanovsky <leonro@...dia.com>, Mark Bloch
	<mbloch@...dia.com>
Subject: Re: [RFC net-next 0/5] devlink: Add unique identifier to devlink port
 function



On 4/25/2025 2:24 AM, Jakub Kicinski wrote:
> External email: Use caution opening links or attachments
> 
> 
> On Wed, 23 Apr 2025 16:50:37 +0300 Moshe Shemesh wrote:
>> A function unique identifier (UID) is a vendor defined string of
>> arbitrary length that universally identifies a function. The function
>> UID can be reported by device drivers via devlink dev info command.
>>
>> This patch set adds UID attribute to devlink port function that reports
>> the UID of the function that pertains to the devlink port. Code is also
>> added to mlx5 as the first user to implement this attribute.
>>
>> The main purpose of adding this attribute is to allow users to
>> unambiguously map between a function and the devlink port that manages
>> it, which might be on another host.
>>
>> For example, one can retrieve the UID of a function using the "devlink
>> dev info" command and then search for the same UID in the output of
>> "devlink port show" command.
>>
>> The "devlink dev info" support for UID of a function is added by a
>> separate patchset [1]. This patchset is submitted as an RFC to
>> illustrate the other side of the solution.
>>
>> Other existing identifiers such as serial_number or board.serial_number
>> are not good enough as they don't guarantee uniqueness per function. For
>> example, in a multi-host NIC all PFs report the same value.
> 
> Makes sense, tho, could you please use UUID?
> Let's use industry standards when possible, not "arbitrary strings".

UUID is limited, like it has to be 128 bits, while here it is variable 
length up to the vendor.
We would like to keep it flexible per vendor. If vendor wants to use 
UUID here, it will work too.