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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <3kjuqbqtgfvklja3hmz55uh3pmlzruynih3lfainmnwzsog4hz@x7x74s2c36vx>
Date: Thu, 24 Apr 2025 11:42:09 +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

Thu, Apr 24, 2025 at 12:17:45AM +0200, kuba@...nel.org wrote:
>On Wed, 23 Apr 2025 13:23:46 +0200 Jiri Pirko wrote:
>> >Because you don't have a PF port for local PF.
>> >
>> >The information you want to convey is which of the PF ports is "local".
>> >I believe we discussed this >5 years ago when I was trying to solve
>> >this exact problem for the NFP.  
>> 
>> If you instantiate a VF devlink instance, you would also like to see
>> "local" VF port? Does not make any sense to me honestly.
>> 
>> Why PF needs to have "local" PF port, isn't it a bit like Uroboros? The
>> PF devlink instance exists, the ports are links to other entities.
>> What's the reason to have a like to itself?
>
>Neither do VF devlink instances in the first place.

Sorry, I don't understand your point.

In VF instance, when there is no eswitch (in theory there could be one).
There is one devlink instance for VF and within that, one devlink port
instance with flavour "virtual". No other port. Simple.

If VF would manage nested eswitch, there would be another ports as
representors to links. This is more theoretical scenario, but I can
imagine VF managing eswitch and spawning SFs under it.

Same for PF. In case PF does not manage eswitch, there is one
devlink instance for the PF and one devlink port with flavour "physical".
In case the PF manages eswitch, there are other devlink ports, each
represents a link to another PF or VF or SF.

What are we missing here? What should be different?

>
>> >The topology information belongs on the ports, not the main instance.  
>> 
>> It's not a topology information. It's an entity property. Take VF for
>> example. VF also exposes FunctionUID under devlink info, same as PF.
>> There is no port instance under VF devlink instance. Same for SF.
>> Do you want to create dummy ports here just to have the "local" link?
>> 
>> I have to be missing something, the drawing as I see it fits 100%.
>
>Very hard to understand where you're coming from since you haven't
>explained why the user has to suddenly care about this new property
>you're adding.

That is simple. Same as we have serial_number and board.serial_number to
provide identification of NIC entities (asic/board), what I'm
introducing is a way to identify function - a function UID.

So 2 PF that belong under same asic would be distinquished by fUID.
Also, if you create couple of VFs, each will have different fUID.

Consider this patchset:
https://lore.kernel.org/netdev/1745416242-1162653-1-git-send-email-moshe@nvidia.com/

That adds a counterpart. PF devlink port function property:
$ devlink port show pci/0000:03:00.0/327680 -jp
{
    "port": {
        "pci/0000:03:00.0/327680": {
            "type": "eth",
            "netdev": "pf0hpf",
            "flavour": "pcipf",
            "controller": 1,
            "pfnum": 0,
            "external": true,
            "splittable": false,
            "function": {
                "hw_addr": "5c:25:73:37:70:5a",
                "roce": "enable",
                "max_io_eqs": 120,
                "uid":
"C6A76AD20605BE026D23C14E70B90704F4A5F5B3F304D83B37000732BF861D48MLNXS0D0F0"
            }
        }
    }
}

This you see on the PF that is managing the eswitch. This devlink port
is a representor of another PF, let's call it PFx. PFx may or may not be
on a different host. It's a link from PF managed eswitch to PFx.

So you have 2 PFs that are in hierarchy (one is on downlink of another),
each on different host.

To find out how these 2 are connected together, you need to know some
identification, on both sides. On PF side, that is port.function.uid the
patchset mentioned above introduces. On PFx, the same value is listed
under devlink info, which is what my patch we are discussing here is
adding.

Is there another way to see how things are connected together, if we
don't expose these identifiers? I don't see it :/

Sorry for not being clear from the beginning. I can extend the docs and
patch description with this info if needed.