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

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

Message-ID: <CAKpbOASJBgx74VFFhMe_+MNMd0OjwjcdKRfVuiFQyBmP4ao0dw@mail.gmail.com>
Date:   Wed, 24 Nov 2021 19:25:10 +0100
From:   Frode Nordahl <frode.nordahl@...onical.com>
To:     Jakub Kicinski <kuba@...nel.org>
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

(Apologies for any duplicates, my mailer somehow introduced HTML parts
which the ML does not like, resending to fix that).

On Wed, Nov 24, 2021 at 6:40 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> 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).

For systems where the NICs are connected to multiple CPUs I have not
seen information about the physical ports exposed to the bare metal
host.

I assume there is an association between the PF and VF ports from devlink POV?

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

The need to associate PF with physical comes from this kind of thing.

In recent kernels the bare metal host PF MAC is exposed through
devlink to the SmartNIC CPU PF representor. However for SmartNIC CPUs
running older kernels this is not available, and some vendors have
provided an interim sysfs interface relative to the physical port
netdev.

So to deal with this the fallback support would need to guess the
association, and we'll just have to hope for recent kernels getting
into the wild sooner.

-- 
Frode Nordahl