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.
