Hi Ajit, >-----Original Message----- >From: Ajit Khaparde <ajit.khapa...@broadcom.com> >Sent: Thursday, January 28, 2021 1:43 AM >To: Xueming(Steven) Li <xuemi...@nvidia.com> >Cc: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>; 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 Tue, Jan 26, 2021 at 7:05 PM Xueming(Steven) Li <xuemi...@nvidia.com> >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. >> 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. >> >> In the future, I think representor could be processed by PMD, so PMD could >have enough flexibility >> to support more device expressions and types. But that will introduce a >fundamental change of devargs and >> device management, need a full plan. >Do you mean all changes will be contained within the PMD? The >fundamental changes will be in the PMD?
Yes, PMD detect device type and IDs from devargs and figure out a unique name for device. >More types of what? SF, representor of SF, representor of VF... > >> >> > >> >Andrew. >>
