All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: ecree@xilinx.com, netdev@vger.kernel.org, linux-net-drivers@amd.com
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, corbet@lwn.net, linux-doc@vger.kernel.org,
	jacob.e.keller@intel.com, jesse.brandeburg@intel.com,
	michael.chan@broadcom.com, andy@greyhouse.net, saeed@kernel.org,
	jiri@resnulli.us, snelson@pensando.io, simon.horman@corigine.com,
	alexander.duyck@gmail.com, rdunlap@infradead.org,
	parav@nvidia.com, roid@nvidia.com, marcin.szycik@linux.intel.com,
	Edward Cree <ecree.xilinx@gmail.com>
Subject: Re: [PATCH v3 net-next] docs: net: add an explanation of VF (and other) Representors
Date: Tue, 6 Sep 2022 16:29:27 +0700	[thread overview]
Message-ID: <228fb86d-4239-0aa9-ba88-e3fdc7cbe99f@gmail.com> (raw)
In-Reply-To: <20220905135557.39233-1-ecree@xilinx.com>

On 9/5/22 20:55, ecree@xilinx.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@gmail.com>

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

  reply	other threads:[~2022-09-06  9:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05 13:55 [PATCH v3 net-next] docs: net: add an explanation of VF (and other) Representors ecree
2022-09-06  9:29 ` Bagas Sanjaya [this message]
2022-09-20 12:40   ` Edward Cree
2022-09-20 13:08     ` Jonathan Corbet
2022-09-21 14:40 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=228fb86d-4239-0aa9-ba88-e3fdc7cbe99f@gmail.com \
    --to=bagasdotme@gmail.com \
    --cc=alexander.duyck@gmail.com \
    --cc=andy@greyhouse.net \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=ecree.xilinx@gmail.com \
    --cc=ecree@xilinx.com \
    --cc=edumazet@google.com \
    --cc=jacob.e.keller@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-net-drivers@amd.com \
    --cc=marcin.szycik@linux.intel.com \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=parav@nvidia.com \
    --cc=rdunlap@infradead.org \
    --cc=roid@nvidia.com \
    --cc=saeed@kernel.org \
    --cc=simon.horman@corigine.com \
    --cc=snelson@pensando.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.