netdev - Re: [PATCH v3 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]

Date:   Tue, 6 Sep 2022 16:29:27 +0700
From:   Bagas Sanjaya <bagasdotme@...il.com>
To:     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, parav@...dia.com,
        roid@...dia.com, marcin.szycik@...ux.intel.com,
        Edward Cree <ecree.xilinx@...il.com>
Subject: Re: [PATCH v3 net-next] docs: net: add an explanation of VF (and
 other) Representors

On 9/5/22 20:55, ecree@...inx.com wrote:
> +Thus, the following should all have representors:
> +
> + - VFs belonging to the switchdev function.
> + - Other PFs on the local PCIe controller, and any VFs belonging to them.
> + - PFs and VFs on external PCIe controllers on the device (e.g. for any embedded
> +   System-on-Chip within the SmartNIC).
> + - PFs and VFs with other personalities, including network block devices (such
> +   as a vDPA virtio-blk PF backed by remote/distributed storage), if (and only
> +   if) their network access is implemented through a virtual switch port. [#]_
> +   Note that such functions can require a representor despite the representee
> +   not having a netdev.
> + - Subfunctions (SFs) belonging to any of the above PFs or VFs, if they have
> +   their own port on the switch (as opposed to using their parent PF's port).
> + - Any accelerators or plugins on the device whose interface to the network is
> +   through a virtual switch port, even if they do not have a corresponding PCIe
> +   PF or VF.
> +
<snipped>
> +
> +.. [#] The concept here is that a hardware IP stack in the device performs the
> +   translation between block DMA requests and network packets, so that only
> +   network packets pass through the virtual port onto the switch.  The network
> +   access that the IP stack "sees" would then be configurable through tc rules;
> +   e.g. its traffic might all be wrapped in a specific VLAN or VxLAN.  However,
> +   any needed configuration of the block device *qua* block device, not being a
> +   networking entity, would not be appropriate for the representor and would
> +   thus use some other channel such as devlink.
> +   Contrast this with the case of a virtio-blk implementation which forwards the
> +   DMA requests unchanged to another PF whose driver then initiates and
> +   terminates IP traffic in software; in that case the DMA traffic would *not*
> +   run over the virtual switch and the virtio-blk PF should thus *not* have a
> +   representor.
> +

I think by convention, footnotes should be put on bottom of the doc.

Other than that, LGTM.

Reviewed-by: Bagas Sanjaya <bagasdotme@...il.com>

-- 
An old man doll... just what I always wanted! - Clara