<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>
