netdev - Re: [PATCH net] netdevsim: Fix physical port index

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211124094023.68010e87@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Wed, 24 Nov 2021 09:40:23 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Frode Nordahl <frode.nordahl@...onical.com>
Cc:     netdev@...r.kernel.org, Jiri Pirko <jiri@...dia.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net] netdevsim: Fix physical port index

On Wed, 24 Nov 2021 17:24:16 +0100 Frode Nordahl wrote:
> I don't care too much about the ID itself starting at 0 per se, but I
> would expect the ID's provided through devlink-port to match between
> the value specified for DEVLINK_ATTR_PORT_PCI_PF_NUMBER on the
> simulated PCI_VF flavoured ports, the value specified for
> DEVLINK_ATTR_PORT_NUMBER on the simulated physical ports and the value
> specified for DEVLINK_ATTR_PORT_PCI_PF_NUMBER  on the simulated PCI_PF
> flavoured ports.
> 
> For a user space application running on a host with a regular
> devlink-enabled NIC (let's say a ConnectX-5), it can figure out the
> relationship between the ports with the regular sysfs API.
> 
> However, for a user space application running on the Arm cores of a
> devlink-enabled SmartNIC with control plane CPUs (let's say a
> BlueField2), the relationship between the representor ports is not
> exposed in the regular sysfs API. So this is where the devlink-port
> interface becomes important. From a PHYSICAL representor I need to
> find which PF representors are associated, from there I need to find
> VF representors associated, and the other way round.

I see, thanks for this explanation.

There is no fundamental association between physical port and PF in
NICs in switchdev mode. Neither does the bare metal host have any
business knowing anything about physical ports (including the number 
of them).

Obviously that's the theory, vendors like to abuse the APIs and cause
all sort of.. fun.