21/12/2023 14:28, Harman Kalra: > From: Thomas Monjalon <tho...@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.
