[PATCH v2 24/24] doc: port representors in cnxk
Thomas Monjalon
thomas at monjalon.net
Wed Dec 20 10:37:34 CET 2023
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.
More information about the dev
mailing list