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

Harman Kalra hkalra at marvell.com
Thu Jan 11 07:48:43 CET 2024


Hi Thomas

Thanks for the review
Please see inline

Thanks
Harman

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: Friday, December 22, 2023 12:04 AM
> To: Harman Kalra <hkalra at marvell.com>
> Cc: Nithin Kumar Dabilpuram <ndabilpuram at marvell.com>; Kiran Kumar
> Kokkilagadda <kirankumark at marvell.com>; Sunil Kumar Kori
> <skori at marvell.com>; Satha Koteswara Rao Kottidi
> <skoteshwar at marvell.com>; dev at dpdk.org; Jerin Jacob Kollanukkaran
> <jerinj at marvell.com>
> Subject: Re: [EXT] Re: [PATCH v2 24/24] doc: port representors in cnxk
> 

<snip>


> >
> > 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.

I have pushed a series for the change:
https://patches.dpdk.org/project/dpdk/list/?series=30781

> 
> 
> > > > +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.

Yes, will remove generic point

> 
> > 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.

Sure, will reword in next series.

> 



More information about the dev mailing list