On 18/08/2022 16:07, Roi Dayan wrote: > On 2022-08-15 5:22 PM, ecree@xxxxxxxxxx wrote: >> +The representor netdevice should *not* directly refer to a PCIe device (e.g. >> +through ``net_dev->dev.parent`` / ``SET_NETDEV_DEV()``), either of the >> +representee or of the master PF. > > Hi, > maybe I'm confused here, but why representor should not refer to pci > device ? it does exists today for systemd renaming. > and this is used beside of implementing the other ndos you mention > below. The master PF is already identified via ``phys_switch_id``, another linkage is not needed and only means that userland looking up netdevices by PCIe address has to do another step to distinguish the PF's own netdev from all the representors. Allegedly[1] nfp ran into issues where OpenStack would sometimes use the reprs for ops that logically should have been on the PF because they all had the same /sys/class/net/$INTF/device and it wasn't smart enough to tell the difference. Semantically, the representor is a virtual device, that's backed by the PF netdevice rather than the PF's hardware directly — even if it has e.g. dedicated queues, it's still not in administrative control of the PCIe function in the way that the PF driver instance is. And compare to e.g. a vlan netdev stacked on top of the PF netdev — we don't put the PF in /sys/class/net/vlan0/device... > $ git grep SET_NETDEV_DEV|grep rep > drivers/net/ethernet/intel/ice/ice_repr.c: SET_NETDEV_DEV(repr->netdev, ice_pf_to_dev(vf->pf)); > drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: SET_NETDEV_DEV(netdev, mdev->device); > drivers/net/ethernet/netronome/nfp/flower/main.c: SET_NETDEV_DEV(repr, &priv->nn->pdev->dev); Yes, several existing drivers do this[2]. IMHO they're wrong. -ed [1]: https://lore.kernel.org/all/20220728113231.26fdfab0@xxxxxxxxxx/ [2]: https://lore.kernel.org/netdev/71af8654-ca69-c492-7e12-ed7ff455a2f1@xxxxxxxxx/
