On 1/19/21 5:24 PM, Xueming(Steven) Li wrote: > >> -----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?
Sorry, but I disagree. Solution with vf1 and pf0vf1 making the same representor ID sounds not acceptable to me. It is definitely different things if I pass it to PF1. >> >> 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? > Current one? Sorry I don't understand. Andrew.
