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: <CAKpbOATgFseXtkWoTcs6bNsvP_4WXChv5ffvtd2+8uqTHmr26w@mail.gmail.com>
Date:   Wed, 24 Nov 2021 17:24:16 +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

On Wed, Nov 24, 2021 at 3:20 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Wed, 24 Nov 2021 09:11:06 +0100 Frode Nordahl wrote:
> > At present when a netdevsim device is added, the first physical
> > port will have an index of 1.  This behavior differ from what any
> > real hardware driver would do, which would start the index at 0.
> >
> > When using netdevsim to test the devlink-port interface this
> > behavior becomes a problem because the provided data is incorrect.
> >
> > Example:
> > $ sudo modprobe netdevsim
> > $ sudo sh -c 'echo "10 1" > /sys/bus/netdevsim/new_device'
> > $ sudo sh -c 'echo 4 > /sys/class/net/eni10np1/device/sriov_numvfs'
> > $ sudo devlink dev eswitch set netdevsim/netdevsim10 mode switchdev
> > $ devlink port show
> > netdevsim/netdevsim10/0: type eth netdev eni10np1 flavour physical port 1
> > netdevsim/netdevsim10/128: type eth netdev eni10npf0vf0 flavour pcivf pfnum 0 vfnum 0
> > netdevsim/netdevsim10/129: type eth netdev eni10npf0vf1 flavour pcivf pfnum 0 vfnum 1
> > netdevsim/netdevsim10/130: type eth netdev eni10npf0vf2 flavour pcivf pfnum 0 vfnum 2
> > netdevsim/netdevsim10/131: type eth netdev eni10npf0vf3 flavour pcivf pfnum 0 vfnum 3
> >
> > With this patch applied you would instead get:
> > $ sudo modprobe netdevsim
> > $ sudo sh -c 'echo "10 1" > /sys/bus/netdevsim/new_device'
> > $ sudo sh -c 'echo 4 > /sys/class/net/eni10np0/device/sriov_numvfs'
> > $ sudo devlink dev eswitch set netdevsim/netdevsim10 mode switchdev
> > $ devlink port show
> > netdevsim/netdevsim10/0: type eth netdev eni10np0 flavour physical port 0
> > netdevsim/netdevsim10/128: type eth netdev eni10npf0vf0 flavour pcivf pfnum 0 vfnum 0
> > netdevsim/netdevsim10/129: type eth netdev eni10npf0vf1 flavour pcivf pfnum 0 vfnum 1
> > netdevsim/netdevsim10/130: type eth netdev eni10npf0vf2 flavour pcivf pfnum 0 vfnum 2
> > netdevsim/netdevsim10/131: type eth netdev eni10npf0vf3 flavour pcivf pfnum 0 vfnum 3
> >
> > The above more accurately resembles what a real system would look
> > like.
> >
> > Fixes: 8320d1459127 ("netdevsim: implement dev probe/remove skeleton with port initialization")
> > Signed-off-by: Frode Nordahl <frode.nordahl@...onical.com>
>
> Why do you care about the port ID starting at 0? It's not guaranteed.
> The device can use any encoding scheme to assign IDs, user space should
> make no assumptions here.

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.

> Please use get_maintainers to CC all the relevant people.

Thank you for pointing that out. Apologies for skipping that step,
added the missing ones now.

-- 
Frode Nordahl