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

Andrew Rybchenko andrew.rybchenko at oktetlabs.ru
Mon Feb 1 09:39:29 CET 2021

On 1/28/21 5:31 PM, Xueming(Steven) Li wrote:
> <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.

sysfs is obviously Linux specific. I think the information
should be available via DPDK API.

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

Hm, I thought about more port representor specific API.
For me it is hard to tell if such generic naming is good or
bad. I think it should be proven that such generic API
makes sense. Any other potential users / use cases?

I've considered ethdev API which returns (in similar way as
above) list of possible port representors which could be
controlled by the device. Also I think it would be useful
to include type information (enum with PF, VF, SF),
controller ID.

There is one more bit which is not in the picture yet -
switch_info.port_id. Should it be equal to representor
ID? Or different and provided in the info structure?

More information about the dev mailing list