[dpdk-dev] [PATCH v8 7/9] ethdev: new API to get representor info

[Ferruh Yigit]

On 3/8/2021 3:31 PM, Xueming(Steven) Li wrote:
> 
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit at intel.com>
>> Sent: Monday, March 8, 2021 10:44 PM
>> To: Xueming(Steven) Li <xuemingl at nvidia.com>; Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>
>> Cc: dev at dpdk.org; Slava Ovsiienko <viacheslavo at nvidia.com>; Asaf Penso <asafp at nvidia.com>; NBU-Contact-Thomas Monjalon
>> <thomas at monjalon.net>; Ray Kinsella <mdr at ashroe.eu>; Neil Horman <nhorman at 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 <xuemingl at nvidia.com>
>>> Acked-by: Andrew Rybchenko <andrew.rybchenko at 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.
> 

Got it thanks.
Intention of the new API seems to get info to be able to calculate the unique 
"representor ID" and the helper function 'rte_eth_representor_id_get()' 
implements a logic to calculate this unique ID but that logic is not clear, can 
you please document it more to help the PMD developers to implement 
'representor_info_get()'?