Thread (6 messages) flat view 6 messages, 2 authors, 2021-11-24

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

From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-11-24 17:40:29

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help