-----Original Message-----
From: Ferruh Yigit <redacted>
Sent: Tuesday, March 9, 2021 12:12 AM
To: Xueming(Steven) Li <redacted>; Andrew Rybchenko <redacted>
Cc: dev@dpdk.org; Slava Ovsiienko <redacted>; Asaf Penso <redacted>; NBU-Contact-Thomas Monjalon
[off-list ref]; Ray Kinsella [off-list ref]; Neil Horman [off-list ref]
Subject: Re: [PATCH v8 7/9] ethdev: new API to get representor info

On 3/8/2021 3:31 PM, Xueming(Steven) Li wrote:

quoted

quoted

-----Original Message-----
From: Ferruh Yigit <redacted>
Sent: Monday, March 8, 2021 10:44 PM
To: Xueming(Steven) Li <redacted>; Andrew Rybchenko
[off-list ref]
Cc: dev@dpdk.org; Slava Ovsiienko <redacted>; Asaf
Penso [off-list ref]; NBU-Contact-Thomas Monjalon
[off-list ref]; Ray Kinsella [off-list ref]; Neil Horman
[off-list ref]
Subject: Re: [PATCH v8 7/9] ethdev: new API to get representor info

On 3/4/2021 2:30 PM, Xueming Li wrote:

quoted

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 <redacted>
Acked-by: Andrew Rybchenko <redacted>

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.

quoted

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()'?

Sure, will update.