On 1/19/21 10:13 AM, Xueming Li wrote: > dedicated queues(txq, rxq). A SF netdev supports E-Switch representation > offload similar to existing PF and VF representors. A SF shares PCI > level resources with other SFs and/or with its parent PCI function. > >>From SmartNIC perspective, when PCI device is shared for multi-host, > representors for host controller and host PF is required. > > This patch set introduces new representor types in addtion to existing > VF representor. Syntax: > > [[c#]pf#]vf#: VF port representor/s from controller/pf > [[c#]pf#]sf#: SF port representor/s from controller/pf > #: VF representor - for backwards compatibility > > "#" is number instance, list or range, valid examples: > 1, [1,3,5], [0-3], [0,2-4,6] > > For backward compatibility, this patch also introduces new netdev > capability to indicate the capability of supportting SF representor.
The patch series looks really nice. Thanks. As before, my biggest concern is making representor ID a bitmap. See my comments to a specific patch. Plus absence of defined semantics of caller function. Basically it is looks like it is assumed that controller #0 and PF #0 is the caller. However, it could be wrong. The next biggest concert is the absence of capability reporting API. How many controller are available? How many PFs on each controller are available? How many VFs on each controller/PF are available? How many SFs? >From the first sight it sounds not that important right now and an extra feature which could be added in the follow up patches, but IMHO addition of the API would allow to avoid making representor ID a bitmap. Basically capabilities API can provide an array of available functions with representor ID assigned to each entry. Also it could make the entire patch series optional since it would allow to interpret numbers in representor=[....] as representor IDs which are mapped to controller/PF/VF/SF by the capabilities reporting API. I realize that sometimes it could be more convenient to use syntax suggested here. Mainly for human.
