[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <l5sll5gx4vw4ykf65vukex3huj677ar5l47iheh4l63e3xtf42@72g3vl5whmek>
Date: Fri, 25 Apr 2025 13:26:01 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Moshe Shemesh <moshe@...dia.com>, 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>, 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
Fri, Apr 25, 2025 at 01:24:25AM +0200, kuba@...nel.org wrote:
>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".
Well, you could make the same request for serial number of asic and board.
Could be uuids too, but they aren't. I mean, it makes sense to have all
uids as uuid, but since the fw already exposes couple of uids as
arbitrary strings, why this one should be treated differently all of the
sudden?
Powered by blists - more mailing lists