[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <o47ap7uhadqrsxpo5uxwv5r2x5uk5zvqrlz36lczake4yvlsat@xx2wmz6rlohi>
Date: Fri, 18 Apr 2025 12:15:01 +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, saeedm@...dia.com, leon@...nel.org, tariqt@...dia.com,
andrew+netdev@...n.ch, horms@...nel.org, donald.hunter@...il.com, parav@...dia.com,
kalesh-anakkur.purayil@...adcom.com
Subject: Re: [PATCH net-next v3 2/3] devlink: add function unique identifier
to devlink dev info
Fri, Apr 18, 2025 at 03:38:22AM +0200, kuba@...nel.org wrote:
>On Wed, 16 Apr 2025 23:41:32 +0200 Jiri Pirko wrote:
>> A physical device may consists of several PCI physical functions.
>> Each of this PCI function's "serial_number" is same because they are
>> part of single board. From this serial number, PCI function cannot be
>> uniquely referenced in a system.
>>
>> Expanding this in slightly more complex system of multi-host
>> "board.serial_number" is not even now unique across two hosts.
>>
>> Further expanding this for DPU based board, a DPU board has PCI
>> functions on the external host as well as DPU internal host.
>> Such DPU side PCI physical functions also have the same "serial_number".
>>
>> There is a need to identify each PCI function uniquely in a factory.
>> We are presently missing this function unique identifier.
>>
>> Hence, introduce a function unique identifier, which is uniquely
>> identifies a function across one or multiple hosts, also has unique
>> identifier with/without DPU based NICs.
>
>Why do you think this should be a property of the instance?
>We have PF ports.
Ports does not look suitable to me. In case of a function with multiple
physical ports, would the same id be listed for multiple ports? What
about representors?
This is a function propertly, therefore it makes sense to me to put it
on devlink instance as devlink instance represents the function.
Another patchset that is most probably follow-up on this by one of my
colleagues will introduce fuid propertly on "devlink port function".
By that and the info exposed by this patch, you would be able to identify
which representor relates to which function cross-hosts. I think that
your question is actually aiming at this, isn't it?
Powered by blists - more mailing lists