Re: [PATCH v2 24/24] doc: port representors in cnxk

[Thomas Monjalon <thomas@monjalon.net>]

19/12/2023 18:40, Harman Kalra:
> +The CNXK driver supports port representor model by adding virtual ethernet
> +ports providing a logical representation in DPDK for physical function(PF) or
> +SR-IOV virtual function (VF) devices for control and monitoring.
> +
> +Base device or parent device underneath these representor ports is a eswitch
> +device which is not a cnxk ethernet device but has NIC RX and TX capabilities.
> +Each representor port is represented by a RQ and SQ pair of this eswitch
> +device.
> +
> +Current implementation supports representors for both physical function and
> +virtual function.

A doc comes with its implementation, so no need to say "current implementation".

> +
> +These port representor ethdev instances can be spawned on an as needed basis
> +through configuration parameters passed to the driver of the underlying
> +base device using devargs ``-a <base PCI BDF>,representor=pf*vf*``
> +
> +.. note::
> +
> +   Representor ports to be created for respective representees should be
> +   defined via these representor devargs.
> +   Eg. To create a representor for representee PF1VF0, devargs to be passed
> +   is ``-a <base PCI BDF>,representor=pf0vf0``
> +
> +   For PF representor
> +   ``-a <base PCI BDF>,representor=pf2``
> +
> +   For defining range of vfs, say 5 representor ports under a PF
> +   ``-a <base PCI BDF>,representor=pf0vf[0-4]``
> +
> +   For representing different VFs under different PFs
> +   ``-a <base PCI BDF>,representor=pf0vf[1,2],representor=pf1vf[2-5]``

It looks like something we should describe globally for ethdev,
instead of driver documentation.

> +In case of exception path (i.e. until the flow definition is offloaded to the
> +hardware), packets transmitted by the VFs shall be received by these
> +representor port, while packets transmitted by representor ports shall be
> +received by respective VFs.

Not clear. How is it related to any offload?

> +On receiving the VF traffic via these representor ports, applications holding
> +these representor ports can decide to offload the traffic flow into the HW.
> +Henceforth the matching traffic shall be directly steered to the respective
> +VFs without being received by the application.

Using "these" makes no sense here. Please prefer "the representor ports".

> +Current virtual representor port PMD supports following operations:

Again, no need of "current".

[...]
>     +---+------------+-------------------------------------------------------+
>     | 2 | NPC        | --log-level='pmd\.net.cnxk\.flow,8'                   |
>     +---+------------+-------------------------------------------------------+
> +   | 3 | REP        | --log-level='pmd\.net.cnxk\.rep,8'                   |
> +   +---+------------+-------------------------------------------------------+
> +   | 4 | ESW        | --log-level='pmd\.net.cnxk\.esw,8'                   |
> +   +---+------------+-------------------------------------------------------+

Why it is not aligned?

> --- a/doc/guides/nics/features/cnxk_vf.ini
> +++ b/doc/guides/nics/features/cnxk_vf.ini
> @@ -64,6 +64,8 @@ mpls                 = Y
>  nvgre                = Y
>  pppoes               = Y
>  raw                  = Y
> +represented_port     = Y
> +port_representor     = Y
>  sctp                 = Y

It should be in alphabetical order.