[EXT] Re: [PATCH v2 24/24] doc: port representors in cnxk
Thomas Monjalon
thomas at monjalon.net
Thu Dec 21 19:33:46 CET 2023
21/12/2023 14:28, Harman Kalra:
> From: Thomas Monjalon <thomas at 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.
More information about the dev
mailing list