netdev - Re: [RFC PATCH v2 net-next] docs: net: add an explanation of VF (and other) Representors

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: <bb31b68c-1303-0f18-eace-74bf7e05cbb1@gmail.com>
Date:   Fri, 19 Aug 2022 16:18:19 +0100
From:   Edward Cree <ecree.xilinx@...il.com>
To:     Roi Dayan <roid@...dia.com>, ecree@...inx.com,
        netdev@...r.kernel.org, linux-net-drivers@....com
Cc:     davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
        edumazet@...gle.com, corbet@....net, linux-doc@...r.kernel.org,
        jacob.e.keller@...el.com, jesse.brandeburg@...el.com,
        michael.chan@...adcom.com, andy@...yhouse.net, saeed@...nel.org,
        jiri@...nulli.us, snelson@...sando.io, simon.horman@...igine.com,
        alexander.duyck@...il.com, rdunlap@...radead.org
Subject: Re: [RFC PATCH v2 net-next] docs: net: add an explanation of VF (and
 other) Representors

On 18/08/2022 16:07, Roi Dayan wrote:
> On 2022-08-15 5:22 PM, ecree@...inx.com 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@kernel.org/
[2]: https://lore.kernel.org/netdev/71af8654-ca69-c492-7e12-ed7ff455a2f1@gmail.com/