>-----Original Message----- >From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> >Sent: Tuesday, January 19, 2021 4:41 PM >To: Xueming(Steven) Li <xuemi...@nvidia.com> >Cc: dev@dpdk.org; Slava Ovsiienko <viachesl...@nvidia.com>; Asaf Penso ><as...@nvidia.com> >Subject: Re: [dpdk-dev] [PATCH v5 0/9] ethdev: support SubFunction >representor > >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.
From devargs syntax perspective, a VF representor on PF1 could be referenced either way: 1: <PF0_BDF>,representor=pf1vfX 2: <PF1_BDF>,representor=vfX 3: <PF1_BDF>,representor=pf0vfX // works but not suggested, use PF0 BDF as caller If probe a device with PF0 BDF and locate it with PF1 BDF, the device iterator will fail, devargs is parsed by api, EAL layer simply compare PCI BDF and then representor ID, i.e. "c#pf#vf#". The caller device should be consistent, better to use the first device. Devrg "<PF1_BDF>,representor=vfX" will work, representor controller ID and pf ID default to #0, relative to caller context PF1 BDF. Is it good to add such suggestion/behavior on rte_eth_devargs comments? > >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. Agree, mostly for human. Regarding to capability reporting API, how about remove current one and enhance it later with a complete patch set?
