Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction representor

["Xueming(Steven) Li" <xuemingl@nvidia.com>]

<snip>
>> The patch of device SF capability, but seems I misunderstood your suggestion.
>> Let me explain process to create a SF:
>> 1. SF can be created on the fly with scripts, unlike VF which is statically pre-created.
>
>Is there a maximum index and maximum total number of SF's created? How to find it?

The maximum index is defined by firmware configuration, all SF's information could be found
from sysfs. To create a SF, both PCI and sfnum have to be specified.

>
>> 2. SF is created on a PF with a SF number. SF number is named per PF, different PF may have same SF number.
>> 3. For standalone PF, hot plug to DPDK using "PF#_BDF,representor=sf#", no need to use pf#sf# here.
>> 4. For bonding netdev, hot plug to DPDK using "PF0_BDF,representor=pf#sf#"
>> If using new api to return all representor IDs, need some way locate
>> the new created SF by PF and SF number, that's why "pf#sf#" is used in this patch set.
>
>I think the API should simply reserve/report space for maximum number of SFs. So, IDs are stable across restart/reboot in assumption
>that NIC is not reconfigured (changed maximum number of VF or maximum number of SFs of any PF).

Yes, IDs should be stable as long as no  NIC firmware configuration change.

Just clarify, this api should be common enough to report all devices that a bus device supports:
1. name, might contains controller and pf info, example: "eth:representor:c0pf1vf"
2. ID range, example: 0-127
The api describes ID ranges for each sub device type, users have to query the api and choose representor ID to probe.

Prototype:
struct rte_bus_device_range {
	char name[64];
	uint32_t base;
	uint32_t number;
}
/* return number of ranges filled, or number of ranges if list is NULL. */
int rte_bus_ dev_range_get(struct rte_bus_device_range *list, int n);


>
<snip>