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

[Thomas Monjalon <thomas@monjalon.net>]

21/12/2023 14:28, Harman Kalra:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 19/12/2023 18:40, Harman Kalra:
> > > +   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.
> 
> DPDK  generic representor devarg parser (rte_eth_devargs_parse_representor_ports()) can parse first
> 3 cases i.e. a <base PCI BDF>,representor=pf0vf0 .... ``-a <base PCI BDF>,representor=pf0vf[0-4]``,
> while 4 case was a special case which our PMD needs.
> 
> Representor devargs are processed as part of new device (eswitch) PMD only, normal CNXK
> PMD won't accept representor as a devarg. Hence all devargs we define under eswitch PCI device
> and all the required representors are created while probing eswitch device probing.
> 
> In the following format we are defining representors for which PFs and VFs should be created:
> Eg. 
> 	-a <base PCI BDF >,representor=pf0vf[1,2],representor=pf1vf[2-5]
> Here
> 	VF representor will be created only for PF0VF1, PF2VF2, PF1VF2.....PF1VF5
> Although there may be n no of PF VF combinations but user wants representors for this devices only.
> 
> Please let us know your opinion if "-a <base PCI BDF >,representor=pf0vf[1,2],representor=pf1vf[2-5]"
> format handling can also be handled in common code. We can push a separate patch for it.

I think yes it could be moved to common code in ethdev.


> > > +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?
> 
> Point what I wanted to highlight here is, until the flow rule for a fastpath is identified
> and installed (offloaded) to the HW, packet flow will take the slow path (exception path)
>  i.e. for every packet sent out via VF should be received by its representor port and
> vice versa.

That's the case for any flow rule, right?
I don't think it is specific to VF and representors.

> Once the application installs the rule packets can take fast path i.e. directly
> from VF to destination (wire or other VF), representors will not come in the 
> datapath for fast processing.

You probably need to rephrase to explain what happens in VF scenario
without being something which looks like an exception.