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

On Wed, Nov 24, 2021 at 3:20 PM Jakub Kicinski [off-list ref] wrote:

On Wed, 24 Nov 2021 09:11:06 +0100 Frode Nordahl wrote:

quoted

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 <redacted>

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