>-----Original Message----- >From: Ferruh Yigit <ferruh.yi...@intel.com> >Sent: Monday, March 8, 2021 10:44 PM >To: Xueming(Steven) Li <xuemi...@nvidia.com>; Andrew Rybchenko ><andrew.rybche...@oktetlabs.ru> >Cc: dev@dpdk.org; Slava Ovsiienko <viachesl...@nvidia.com>; Asaf Penso ><as...@nvidia.com>; NBU-Contact-Thomas Monjalon ><tho...@monjalon.net>; Ray Kinsella <m...@ashroe.eu>; Neil Horman ><nhor...@tuxdriver.com> >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 <xuemi...@nvidia.com> >> Acked-by: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> > >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.
