>-----Original Message----- >From: Ferruh Yigit <[email protected]> >Sent: Monday, March 8, 2021 10:44 PM >To: Xueming(Steven) Li <[email protected]>; Andrew Rybchenko ><[email protected]> >Cc: [email protected]; Slava Ovsiienko <[email protected]>; Asaf Penso ><[email protected]>; NBU-Contact-Thomas Monjalon ><[email protected]>; Ray Kinsella <[email protected]>; Neil Horman ><[email protected]> >Subject: Re: [PATCH v8 7/9] ethdev: new API to get representor info > >On 3/4/2021 2:30 PM, Xueming Li wrote: >> The NIC can have multiple PCIe links and can be attached to multiple >> hosts, for example the same single NIC can be shared for multiple >> server units in the rack. On each PCIe link NIC can provide multiple >> PFs and VFs/SFs based on these ones. The full representor identifier >> consists of three indices - controller index, PF index, and VF or SF index >> (if any). >> >> This patch introduces a new API rte_eth_representor_info_get() to >> retrieve representor corresponding info mapping: >> - caller controller index and pf index. >> - supported representor ID ranges. >> - type, controller, pf and start vf/sf ID of each range. >> The API is useful to convert representor from devargs to representor ID. >> >> New ethdev callback representor_info_get() is added to retrieve info >> from PMD driver, optional for PMD that doesn't support new devargs >> representor syntax. >> >> Signed-off-by: Xueming Li <[email protected]> >> Acked-by: Andrew Rybchenko <[email protected]> > >This is middle layer implementation, and there is not problem with it but >without PMD and application implementations it is harder to >get why/how this API will be used. > >As far as I can see this API is not directly needed for this set, what do you >think making this another set with PMD and application >implementations on top of current set?
Hi Ferruh, Thanks for checking this! The patch next, 8/9 which update device iterator for SF representor needs this API to get representor ID then compare.
