| Message ID | 20220214112619.219761-2-tianfei.zhang@intel.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add Intel OFS support for DFL driver | expand |
Hi, Just a couple of nits on ReST formatting. On Mon, 14 Feb 2022 06:26:13 -0500, Tianfei zhang <tianfei.zhang@intel.com> wrote: > From: Tianfei Zhang <tianfei.zhang@intel.com> > > This patch adds description about IOFS support for DFL. > > Signed-off-by: Tianfei Zhang <tianfei.zhang@intel.com> > --- > Documentation/fpga/dfl.rst | 99 +++++++++++++++++++++++++++++++++++++- > 1 file changed, 97 insertions(+), 2 deletions(-) > > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst > index ef9eec71f6f3..6f9eae1c1697 100644 > --- a/Documentation/fpga/dfl.rst > +++ b/Documentation/fpga/dfl.rst > @@ -58,7 +58,10 @@ interface to FPGA, e.g. the FPGA Management Engine (FME) and Port (more > descriptions on FME and Port in later sections). > > Accelerated Function Unit (AFU) represents an FPGA programmable region and > -always connects to a FIU (e.g. a Port) as its child as illustrated above. > +always connects to a FIU (e.g. a Port) as its child as illustrated above, but > +on IOFS design, it introducing Port Gasket which contains AFUs. For DFL perspective, > +the Next_AFU pointer on FIU feature header can point to NULL so the AFU is not > +connects to a FIU(more descriptions on IOFS in later section). > > Private Features represent sub features of the FIU and AFU. They could be > various function blocks with different IDs, but all private features which > @@ -134,6 +137,9 @@ reconfigurable region containing an AFU. It controls the communication from SW > to the accelerator and exposes features such as reset and debug. Each FPGA > device may have more than one port, but always one AFU per port. > > +On IOFS, it introducing a new hardware unit, Port Gasket, which contains all > +the PR specific modules and regions (more descriptions on IOFS in later section). > + > > AFU > === > @@ -143,6 +149,9 @@ used for accelerator-specific control registers. > User-space applications can acquire exclusive access to an AFU attached to a > port by using open() on the port device node and release it using close(). > > +On IOFS, the AFU is embedded in a Port Gasket. The AFU resource can expose via > +VFs with SRIOV support (more descriptions on IOFS in later section). > + > The following functions are exposed through ioctls: > > - Get driver API version (DFL_FPGA_GET_API_VERSION) > @@ -284,7 +293,8 @@ FME is always accessed through the physical function (PF). > > Ports (and related AFUs) are accessed via PF by default, but could be exposed > through virtual function (VF) devices via PCIe SRIOV. Each VF only contains > -1 Port and 1 AFU for isolation. Users could assign individual VFs (accelerators) > +1 Port (On IOFS design, the VF is designs without Port) and 1 AFU for isolation. > +Users could assign individual VFs (accelerators) > created via PCIe SRIOV interface, to virtual machines. > > The driver organization in virtualization case is illustrated below: > @@ -389,6 +399,91 @@ The device nodes used for ioctl() or mmap() can be referenced through:: > /sys/class/fpga_region/<regionX>/<dfl-fme.n>/dev > /sys/class/fpga_region/<regionX>/<dfl-port.n>/dev > > +Intel Open FPGA stack > +===================== Here you need an empty line. > +Intel Open FPGA stack aka IOFS, Intel's version of a common core set of > +RTL to allow customers to easily interface to logic and IP on the FPGA. > +IOFS leverage the DFL for the implementation of the FPGA RTL design. > + > +IOFS designs allow for the arrangement of software interfaces across multiple > +PCIe endpoints. Some of these interfaces may be PFs defined in the static region > +that connect to interfaces in an IP that is loaded via Partial Reconfiguration (PR). > +And some of these interfaces may be VFs defined in the PR region that can be > +reconfigured by the end-user. Furthermore, these PFs/VFs may also be arranged > +using a DFL such that features may be discovered and accessed in user space > +(with the aid of a generic kernel driver like vfio-pci). The diagram below depicts > +an example design with two PFs and two VFs. In this example, PF1 implements its > +MMIO space such that it is compatible with the VirtIO framework. The other functions, > +VF0 and VF1, leverage VFIO to export the MMIO space to an application or a hypervisor. > + For an ASCII-art to be recognized as such, you need a leading "::" here. :: > + +-----------------+ +--------------+ +-------------+ +------------+ > + | FPGA Managerment| | VirtIO | | User App | | Virtual | > + | App | | App | | | | Machine | > + +--------+--------+ +------+-------+ +------+------+ +-----+------+ > + | | | | > + | | | | > + +--------+--------+ +------+-------+ +------+------+ | > + | DFL Driver | |VirtIO driver | | VFIO | | > + +--------+--------+ +------+-------+ +------+------+ | > + | | | | > + | | | | > + +--------+--------+ +------+-------+ +------+------+ +----+------+ > + | PF0 | | PF1 | | PF0_VF0 | | PF0_VF1 | > + +-----------------+ +--------------+ +-------------+ +-----------+ > + > +On IOFS, it introducing some enhancements compared with original DFL design. Again, you need an empty line here. > +1. It introducing Port Gasket in PF0 which is responsible for FPGA management, > +like FME and Port management. The Port Gasket contains all the PR specific modules > +and logic, e.g., PR slot reset/freeze control, user clock, remote STP etc. > +Architecturally, a Port Gasket can have multiple PR slots where user workload can > +be programmed into. > +2. To expend the scalable of FPGA, it can support multiple FPs in static region > +which contain some static functions like VirtIO, diagnostic test, and access over > +VFIO or assigned to VMs easily. Those PFs will not have a Port Unit which without > +PR region (AFU) connected to those PFs, and the end-user cannot partial reconfigurate > +those PFs. > +3. In our previous DFL design, it can only create one VF based in an AFU. To raise > +the efficiency usage of AFU, it can create more than one VFs in an AFU via PCIe > +SRIOV, so those VFs share the PR region and resource. This enumeration list needs some indent tweaks. 1. It introducing Port Gasket in PF0 which is responsible for FPGA management, like FME and Port management. The Port Gasket contains all the PR specific modules and logic, e.g., PR slot reset/freeze control, user clock, remote STP etc. Architecturally, a Port Gasket can have multiple PR slots where user workload can be programmed into. 2. To expend the scalable of FPGA, it can support multiple FPs in static region which contain some static functions like VirtIO, diagnostic test, and access over VFIO or assigned to VMs easily. Those PFs will not have a Port Unit which without PR region (AFU) connected to those PFs, and the end-user cannot partial reconfigurate those PFs. 3. In our previous DFL design, it can only create one VF based in an AFU. To raise the efficiency usage of AFU, it can create more than one VFs in an AFU via PCIe SRIOV, so those VFs share the PR region and resource. > + > +There is one reference architecture design for IOFS as illustrated below: :: (This "::" can also lead an ASCII-art.) > + > + +----------------------+ > + | PF/VF mux/demux | > + +--+--+-----+------+-+-+ > + | | | | | > + +------------------------+ | | | | > + PF0 | +---------+ +-+ | | > + +---+---+ | +---+----+ | | > + | DFH | | | DFH | | | > + +-------+ +-----+----+ +--------+ | | > + | FME | | VirtIO | | Test | | | > + +-------+ +----------+ +--------+ | | > + | Port | PF1 PF2 | | > + +---+---+ | | > + | +----------+ | > + | | ++ > + | | | > + | | PF0_VF0 | PF0_VF1 > + | +-----------------+-----------+------------+ > + | | +-----+-----------+--------+ | > + | | | | | | | > + | | +------+ | +--+ -+ +--+---+ | | > + | | | CSR | | | DFH | | DFH | | | > + +-----------+ +------+ | +-----+ +------+ | | > + | | | DEV | | DEV | | | > + | | +-----+ +------+ | | > + | | PR Slot | | > + | +--------------------------+ | > + | Port Gasket | > + +------------------------------------------+ > + > +Here are the major changes about DFL structures on IOFS implementation design: Again, you need an empty line. > +1. The Port Gasket connects to FIU Port in DFL, but the Next_AFU pointer in > +FIU feature header can point to NULL so that it is no AFU connects to a FIU > +Port. > +2. The VF which include in PR region can start with AFU feature header without > +a FIU Port feature header. As above, this list should look: 1. The Port Gasket connects to FIU Port in DFL, but the Next_AFU pointer in FIU feature header can point to NULL so that it is no AFU connects to a FIU Port. 2. The VF which include in PR region can start with AFU feature header without a FIU Port feature header. > > Performance Counters > ==================== > -- > 2.17.1 I'd recommend running "make htmdocs" and see if the pages are rendered as you expect. Thanks, Akira
On 2/14/22 04:18, Akira Yokosawa wrote: > Hi, > > Just a couple of nits on ReST formatting. > Thanks :) > > I'd recommend running "make htmdocs" and see if the pages are rendered as you > expect. I think that's "make htmldocs". But please do use it.
> -----Original Message----- > From: Randy Dunlap <rdunlap@infradead.org> > Sent: Tuesday, February 15, 2022 1:57 AM > To: Akira Yokosawa <akiyks@gmail.com>; Zhang, Tianfei > <tianfei.zhang@intel.com> > Cc: corbet@lwn.net; Wu, Hao <hao.wu@intel.com>; linux- > doc@vger.kernel.org; linux-fpga@vger.kernel.org; linux- > kernel@vger.kernel.org; mdf@kernel.org; trix@redhat.com; Xu, Yilun > <yilun.xu@intel.com> > Subject: Re: [PATCH v1 1/7] Documentation: fpga: dfl: add description of IOFS > > > > On 2/14/22 04:18, Akira Yokosawa wrote: > > Hi, > > > > Just a couple of nits on ReST formatting. > > > > Thanks :) > > > > > > I'd recommend running "make htmdocs" and see if the pages are rendered > > as you expect. > > I think that's "make htmldocs". But please do use it. Thanks，I will fix it on next version. > > -- > ~Randy
On 2/14/22 3:26 AM, Tianfei zhang wrote: > From: Tianfei Zhang <tianfei.zhang@intel.com> > > This patch adds description about IOFS support for DFL. > This needs work. Several times 'Port Gasket' was mentioned but there is no section describing what it is. It is not clear if iofs supersedes dfl or extends it. It is not clear how a driver probes to tell the difference between the two. This document should set up why the other changes in the patchset are needed. Add yourself to authors list. Tom > Signed-off-by: Tianfei Zhang <tianfei.zhang@intel.com> > --- > Documentation/fpga/dfl.rst | 99 +++++++++++++++++++++++++++++++++++++- > 1 file changed, 97 insertions(+), 2 deletions(-) > > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst > index ef9eec71f6f3..6f9eae1c1697 100644 > --- a/Documentation/fpga/dfl.rst > +++ b/Documentation/fpga/dfl.rst > @@ -58,7 +58,10 @@ interface to FPGA, e.g. the FPGA Management Engine (FME) and Port (more > descriptions on FME and Port in later sections). > > Accelerated Function Unit (AFU) represents an FPGA programmable region and > -always connects to a FIU (e.g. a Port) as its child as illustrated above. > +always connects to a FIU (e.g. a Port) as its child as illustrated above, but > +on IOFS design, it introducing Port Gasket which contains AFUs. For DFL perspective, > +the Next_AFU pointer on FIU feature header can point to NULL so the AFU is not > +connects to a FIU(more descriptions on IOFS in later section). > > Private Features represent sub features of the FIU and AFU. They could be > various function blocks with different IDs, but all private features which > @@ -134,6 +137,9 @@ reconfigurable region containing an AFU. It controls the communication from SW > to the accelerator and exposes features such as reset and debug. Each FPGA > device may have more than one port, but always one AFU per port. > > +On IOFS, it introducing a new hardware unit, Port Gasket, which contains all > +the PR specific modules and regions (more descriptions on IOFS in later section). > + > > AFU > === > @@ -143,6 +149,9 @@ used for accelerator-specific control registers. > User-space applications can acquire exclusive access to an AFU attached to a > port by using open() on the port device node and release it using close(). > > +On IOFS, the AFU is embedded in a Port Gasket. The AFU resource can expose via > +VFs with SRIOV support (more descriptions on IOFS in later section). > + > The following functions are exposed through ioctls: > > - Get driver API version (DFL_FPGA_GET_API_VERSION) > @@ -284,7 +293,8 @@ FME is always accessed through the physical function (PF). > > Ports (and related AFUs) are accessed via PF by default, but could be exposed > through virtual function (VF) devices via PCIe SRIOV. Each VF only contains > -1 Port and 1 AFU for isolation. Users could assign individual VFs (accelerators) > +1 Port (On IOFS design, the VF is designs without Port) and 1 AFU for isolation. > +Users could assign individual VFs (accelerators) > created via PCIe SRIOV interface, to virtual machines. > > The driver organization in virtualization case is illustrated below: > @@ -389,6 +399,91 @@ The device nodes used for ioctl() or mmap() can be referenced through:: > /sys/class/fpga_region/<regionX>/<dfl-fme.n>/dev > /sys/class/fpga_region/<regionX>/<dfl-port.n>/dev > > +Intel Open FPGA stack > +===================== > +Intel Open FPGA stack aka IOFS, Intel's version of a common core set of > +RTL to allow customers to easily interface to logic and IP on the FPGA. > +IOFS leverage the DFL for the implementation of the FPGA RTL design. > + > +IOFS designs allow for the arrangement of software interfaces across multiple > +PCIe endpoints. Some of these interfaces may be PFs defined in the static region > +that connect to interfaces in an IP that is loaded via Partial Reconfiguration (PR). > +And some of these interfaces may be VFs defined in the PR region that can be > +reconfigured by the end-user. Furthermore, these PFs/VFs may also be arranged > +using a DFL such that features may be discovered and accessed in user space > +(with the aid of a generic kernel driver like vfio-pci). The diagram below depicts > +an example design with two PFs and two VFs. In this example, PF1 implements its > +MMIO space such that it is compatible with the VirtIO framework. The other functions, > +VF0 and VF1, leverage VFIO to export the MMIO space to an application or a hypervisor. > + > + +-----------------+ +--------------+ +-------------+ +------------+ > + | FPGA Managerment| | VirtIO | | User App | | Virtual | > + | App | | App | | | | Machine | > + +--------+--------+ +------+-------+ +------+------+ +-----+------+ > + | | | | > + | | | | > + +--------+--------+ +------+-------+ +------+------+ | > + | DFL Driver | |VirtIO driver | | VFIO | | > + +--------+--------+ +------+-------+ +------+------+ | > + | | | | > + | | | | > + +--------+--------+ +------+-------+ +------+------+ +----+------+ > + | PF0 | | PF1 | | PF0_VF0 | | PF0_VF1 | > + +-----------------+ +--------------+ +-------------+ +-----------+ > + > +On IOFS, it introducing some enhancements compared with original DFL design. > +1. It introducing Port Gasket in PF0 which is responsible for FPGA management, > +like FME and Port management. The Port Gasket contains all the PR specific modules > +and logic, e.g., PR slot reset/freeze control, user clock, remote STP etc. > +Architecturally, a Port Gasket can have multiple PR slots where user workload can > +be programmed into. > +2. To expend the scalable of FPGA, it can support multiple FPs in static region > +which contain some static functions like VirtIO, diagnostic test, and access over > +VFIO or assigned to VMs easily. Those PFs will not have a Port Unit which without > +PR region (AFU) connected to those PFs, and the end-user cannot partial reconfigurate > +those PFs. > +3. In our previous DFL design, it can only create one VF based in an AFU. To raise > +the efficiency usage of AFU, it can create more than one VFs in an AFU via PCIe > +SRIOV, so those VFs share the PR region and resource. > + > +There is one reference architecture design for IOFS as illustrated below: > + > + +----------------------+ > + | PF/VF mux/demux | > + +--+--+-----+------+-+-+ > + | | | | | > + +------------------------+ | | | | > + PF0 | +---------+ +-+ | | > + +---+---+ | +---+----+ | | > + | DFH | | | DFH | | | > + +-------+ +-----+----+ +--------+ | | > + | FME | | VirtIO | | Test | | | > + +-------+ +----------+ +--------+ | | > + | Port | PF1 PF2 | | > + +---+---+ | | > + | +----------+ | > + | | ++ > + | | | > + | | PF0_VF0 | PF0_VF1 > + | +-----------------+-----------+------------+ > + | | +-----+-----------+--------+ | > + | | | | | | | > + | | +------+ | +--+ -+ +--+---+ | | > + | | | CSR | | | DFH | | DFH | | | > + +-----------+ +------+ | +-----+ +------+ | | > + | | | DEV | | DEV | | | > + | | +-----+ +------+ | | > + | | PR Slot | | > + | +--------------------------+ | > + | Port Gasket | > + +------------------------------------------+ > + > +Here are the major changes about DFL structures on IOFS implementation design: > +1. The Port Gasket connects to FIU Port in DFL, but the Next_AFU pointer in > +FIU feature header can point to NULL so that it is no AFU connects to a FIU > +Port. > +2. The VF which include in PR region can start with AFU feature header without > +a FIU Port feature header. > > Performance Counters > ====================
> Subject: [PATCH v1 1/7] Documentation: fpga: dfl: add description of IOFS > > From: Tianfei Zhang <tianfei.zhang@intel.com> > > This patch adds description about IOFS support for DFL. > > Signed-off-by: Tianfei Zhang <tianfei.zhang@intel.com> > --- > Documentation/fpga/dfl.rst | 99 +++++++++++++++++++++++++++++++++++++- > 1 file changed, 97 insertions(+), 2 deletions(-) > > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst > index ef9eec71f6f3..6f9eae1c1697 100644 > --- a/Documentation/fpga/dfl.rst > +++ b/Documentation/fpga/dfl.rst > @@ -58,7 +58,10 @@ interface to FPGA, e.g. the FPGA Management Engine > (FME) and Port (more > descriptions on FME and Port in later sections). > > Accelerated Function Unit (AFU) represents an FPGA programmable region and > -always connects to a FIU (e.g. a Port) as its child as illustrated above. > +always connects to a FIU (e.g. a Port) as its child as illustrated above, but > +on IOFS design, it introducing Port Gasket which contains AFUs. For DFL > perspective, > +the Next_AFU pointer on FIU feature header can point to NULL so the AFU is > not > +connects to a FIU(more descriptions on IOFS in later section). > > Private Features represent sub features of the FIU and AFU. They could be > various function blocks with different IDs, but all private features which > @@ -134,6 +137,9 @@ reconfigurable region containing an AFU. It controls the > communication from SW > to the accelerator and exposes features such as reset and debug. Each FPGA > device may have more than one port, but always one AFU per port. > > +On IOFS, it introducing a new hardware unit, Port Gasket, which contains all > +the PR specific modules and regions (more descriptions on IOFS in later section). What's the different between the PORT we have now for DFH, and the new one in IOFS? > + > > AFU > === > @@ -143,6 +149,9 @@ used for accelerator-specific control registers. > User-space applications can acquire exclusive access to an AFU attached to a > port by using open() on the port device node and release it using close(). > > +On IOFS, the AFU is embedded in a Port Gasket. The AFU resource can expose > via > +VFs with SRIOV support (more descriptions on IOFS in later section). > + > The following functions are exposed through ioctls: > > - Get driver API version (DFL_FPGA_GET_API_VERSION) > @@ -284,7 +293,8 @@ FME is always accessed through the physical function > (PF). > > Ports (and related AFUs) are accessed via PF by default, but could be exposed > through virtual function (VF) devices via PCIe SRIOV. Each VF only contains > -1 Port and 1 AFU for isolation. Users could assign individual VFs (accelerators) > +1 Port (On IOFS design, the VF is designs without Port) and 1 AFU for isolation. > +Users could assign individual VFs (accelerators) > created via PCIe SRIOV interface, to virtual machines. > > The driver organization in virtualization case is illustrated below: > @@ -389,6 +399,91 @@ The device nodes used for ioctl() or mmap() can be > referenced through:: > /sys/class/fpga_region/<regionX>/<dfl-fme.n>/dev > /sys/class/fpga_region/<regionX>/<dfl-port.n>/dev > > +Intel Open FPGA stack > +===================== > +Intel Open FPGA stack aka IOFS, Intel's version of a common core set of > +RTL to allow customers to easily interface to logic and IP on the FPGA. > +IOFS leverage the DFL for the implementation of the FPGA RTL design. > + > +IOFS designs allow for the arrangement of software interfaces across multiple > +PCIe endpoints. Some of these interfaces may be PFs defined in the static > region > +that connect to interfaces in an IP that is loaded via Partial Reconfiguration > (PR). > +And some of these interfaces may be VFs defined in the PR region that can be > +reconfigured by the end-user. Furthermore, these PFs/VFs may also be > arranged > +using a DFL such that features may be discovered and accessed in user space > +(with the aid of a generic kernel driver like vfio-pci). The diagram below depicts > +an example design with two PFs and two VFs. In this example, PF1 implements > its > +MMIO space such that it is compatible with the VirtIO framework. The other > functions, > +VF0 and VF1, leverage VFIO to export the MMIO space to an application or a > hypervisor. So PORT will never be exposed to VM in IOFS design, is my understanding correct? > + > + +-----------------+ +--------------+ +-------------+ +------------+ > + | FPGA Managerment| | VirtIO | | User App | | Virtual | s/Managerment/Management/ > + | App | | App | | | | Machine | > + +--------+--------+ +------+-------+ +------+------+ +-----+------+ > + | | | | > + | | | | > + +--------+--------+ +------+-------+ +------+------+ | > + | DFL Driver | |VirtIO driver | | VFIO | | > + +--------+--------+ +------+-------+ +------+------+ | > + | | | | > + | | | | > + +--------+--------+ +------+-------+ +------+------+ +----+------+ > + | PF0 | | PF1 | | PF0_VF0 | | PF0_VF1 | > + +-----------------+ +--------------+ +-------------+ +-----------+ > + > +On IOFS, it introducing some enhancements compared with original DFL design. > +1. It introducing Port Gasket in PF0 which is responsible for FPGA management, > +like FME and Port management. The Port Gasket contains all the PR specific > modules So in IOFS, in PF0, we always have FME and PORT DFH, is my understanding correct? Then why we need patch #3? Another question is in IOFS, do we need to support multiple PR regions/Ports? If that is the case, how should we know which VFs belongs to PORT1 or PORT2? > +and logic, e.g., PR slot reset/freeze control, user clock, remote STP etc. > +Architecturally, a Port Gasket can have multiple PR slots where user workload > can > +be programmed into. > +2. To expend the scalable of FPGA, it can support multiple FPs in static region s/FPs/PFs/ > +which contain some static functions like VirtIO, diagnostic test, and access over > +VFIO or assigned to VMs easily. Those PFs will not have a Port Unit which > without > +PR region (AFU) connected to those PFs, and the end-user cannot partial > reconfigurate s/reconfigurate/reconfigure/ > +those PFs. > +3. In our previous DFL design, it can only create one VF based in an AFU. To > raise > +the efficiency usage of AFU, it can create more than one VFs in an AFU via PCIe > +SRIOV, so those VFs share the PR region and resource. > + > +There is one reference architecture design for IOFS as illustrated below: > + > + +----------------------+ > + | PF/VF mux/demux | > + +--+--+-----+------+-+-+ > + | | | | | > + +------------------------+ | | | | > + PF0 | +---------+ +-+ | | > + +---+---+ | +---+----+ | | > + | DFH | | | DFH | | | > + +-------+ +-----+----+ +--------+ | | > + | FME | | VirtIO | | Test | | | > + +-------+ +----------+ +--------+ | | > + | Port | PF1 PF2 | | > + +---+---+ | | > + | +----------+ | > + | | ++ > + | | | > + | | PF0_VF0 | PF0_VF1 > + | +-----------------+-----------+------------+ > + | | +-----+-----------+--------+ | > + | | | | | | | > + | | +------+ | +--+ -+ +--+---+ | | > + | | | CSR | | | DFH | | DFH | | | > + +-----------+ +------+ | +-----+ +------+ | | > + | | | DEV | | DEV | | | > + | | +-----+ +------+ | | > + | | PR Slot | | > + | +--------------------------+ | > + | Port Gasket | > + +------------------------------------------+ > + > +Here are the major changes about DFL structures on IOFS implementation > design: > +1. The Port Gasket connects to FIU Port in DFL, but the Next_AFU pointer in > +FIU feature header can point to NULL so that it is no AFU connects to a FIU > +Port. > +2. The VF which include in PR region can start with AFU feature header without > +a FIU Port feature header. What about PF2 in static region? Which type of DFH will be used? Thanks Hao > > Performance Counters > ==================== > -- > 2.17.1
> -----Original Message----- > From: Wu, Hao <hao.wu@intel.com> > Sent: Wednesday, February 16, 2022 11:35 AM > To: Zhang, Tianfei <tianfei.zhang@intel.com>; trix@redhat.com; > mdf@kernel.org; Xu, Yilun <yilun.xu@intel.com>; linux-fpga@vger.kernel.org; > linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: corbet@lwn.net > Subject: Re: [PATCH v1 1/7] Documentation: fpga: dfl: add description of IOFS > > > Subject: [PATCH v1 1/7] Documentation: fpga: dfl: add description of > > IOFS > > > > From: Tianfei Zhang <tianfei.zhang@intel.com> > > > > This patch adds description about IOFS support for DFL. > > > > Signed-off-by: Tianfei Zhang <tianfei.zhang@intel.com> > > --- > > Documentation/fpga/dfl.rst | 99 > > +++++++++++++++++++++++++++++++++++++- > > 1 file changed, 97 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst > > index ef9eec71f6f3..6f9eae1c1697 100644 > > --- a/Documentation/fpga/dfl.rst > > +++ b/Documentation/fpga/dfl.rst > > @@ -58,7 +58,10 @@ interface to FPGA, e.g. the FPGA Management Engine > > (FME) and Port (more > > descriptions on FME and Port in later sections). > > > > Accelerated Function Unit (AFU) represents an FPGA programmable > > region and -always connects to a FIU (e.g. a Port) as its child as illustrated > above. > > +always connects to a FIU (e.g. a Port) as its child as illustrated > > +above, but on IOFS design, it introducing Port Gasket which contains > > +AFUs. For DFL > > perspective, > > +the Next_AFU pointer on FIU feature header can point to NULL so the > > +AFU is > > not > > +connects to a FIU(more descriptions on IOFS in later section). > > > > Private Features represent sub features of the FIU and AFU. They > > could be various function blocks with different IDs, but all private > > features which @@ -134,6 +137,9 @@ reconfigurable region containing an > > AFU. It controls the communication from SW to the accelerator and > > exposes features such as reset and debug. Each FPGA device may have > > more than one port, but always one AFU per port. > > > > +On IOFS, it introducing a new hardware unit, Port Gasket, which > > +contains all the PR specific modules and regions (more descriptions on IOFS in > later section). > > What's the different between the PORT we have now for DFH, and the new one > in IOFS? From DFL perspective , the PORT concept is identical between IOFS and old card like N3000 card. The major different is that the IOFS introducing a new hardware concept: Port Gasket, which include the PR slot, Port control, Port user clock control and Port errors. > > > + > > > > AFU > > === > > @@ -143,6 +149,9 @@ used for accelerator-specific control registers. > > User-space applications can acquire exclusive access to an AFU > > attached to a port by using open() on the port device node and release it using > close(). > > > > +On IOFS, the AFU is embedded in a Port Gasket. The AFU resource can > > +expose > > via > > +VFs with SRIOV support (more descriptions on IOFS in later section). > > + > > The following functions are exposed through ioctls: > > > > - Get driver API version (DFL_FPGA_GET_API_VERSION) @@ -284,7 +293,8 > > @@ FME is always accessed through the physical function (PF). > > > > Ports (and related AFUs) are accessed via PF by default, but could be > > exposed through virtual function (VF) devices via PCIe SRIOV. Each VF > > only contains > > -1 Port and 1 AFU for isolation. Users could assign individual VFs > > (accelerators) > > +1 Port (On IOFS design, the VF is designs without Port) and 1 AFU for > isolation. > > +Users could assign individual VFs (accelerators) > > created via PCIe SRIOV interface, to virtual machines. > > > > The driver organization in virtualization case is illustrated below: > > @@ -389,6 +399,91 @@ The device nodes used for ioctl() or mmap() can > > be referenced through:: > > /sys/class/fpga_region/<regionX>/<dfl-fme.n>/dev > > /sys/class/fpga_region/<regionX>/<dfl-port.n>/dev > > > > +Intel Open FPGA stack > > +===================== > > +Intel Open FPGA stack aka IOFS, Intel's version of a common core set > > +of RTL to allow customers to easily interface to logic and IP on the FPGA. > > +IOFS leverage the DFL for the implementation of the FPGA RTL design. > > + > > +IOFS designs allow for the arrangement of software interfaces across > > +multiple PCIe endpoints. Some of these interfaces may be PFs defined > > +in the static > > region > > +that connect to interfaces in an IP that is loaded via Partial > > +Reconfiguration > > (PR). > > +And some of these interfaces may be VFs defined in the PR region that > > +can be reconfigured by the end-user. Furthermore, these PFs/VFs may > > +also be > > arranged > > +using a DFL such that features may be discovered and accessed in user > > +space (with the aid of a generic kernel driver like vfio-pci). The > > +diagram below depicts an example design with two PFs and two VFs. In > > +this example, PF1 implements > > its > > +MMIO space such that it is compatible with the VirtIO framework. The > > +other > > functions, > > +VF0 and VF1, leverage VFIO to export the MMIO space to an application > > +or a > > hypervisor. > > So PORT will never be exposed to VM in IOFS design, is my understanding > correct? On IOFS, there are many methods to access the AFU for virtualization and non-virtualization usage. 1. Legacy Model. This is used for N3000 and N5000 card. In this model the entire AFU region is a unit of PR, and there is a Port device connected to this AFU. In this model, the follow of exposing to VM is the same we have in N3000 and N5000 card. The major follow is: * release the port device. * configure the SRIOV * assign the VF to VM * put the port device back to PF after finished access in VM 2. Micro-Personas in AFU. IOFS intruding new model for PR and AFU access. Micro-Personas allow the RTL developer to designate their own AFU-defined PR regions. In this model, each PR slot has a dedicate Port device, the follow of exposing to VM is the same we have in N3000 and N5000 card. 3. Multiple VFs per PR slot. In this method, we can instance multiple VFs over SRIOV for one PR slot, and access the AFU resource by different VFs in virtualization usage. In this case, the Port device would not connected to AFU/PR slot, so we don't need to release the Port device. before we assign the VF to VM. Which model will deploy in IOFS product depends on the RTL developer. > > > + > > + +-----------------+ +--------------+ +-------------+ +------------+ > > + | FPGA Managerment| | VirtIO | | User App | | Virtual | > > s/Managerment/Management/ Thanks, I will fix it on next version. > > > + | App | | App | | | | Machine | > > + +--------+--------+ +------+-------+ +------+------+ +-----+------+ > > + | | | | > > + | | | | > > + +--------+--------+ +------+-------+ +------+------+ | > > + | DFL Driver | |VirtIO driver | | VFIO | | > > + +--------+--------+ +------+-------+ +------+------+ | > > + | | | | > > + | | | | > > + +--------+--------+ +------+-------+ +------+------+ +----+------+ > > + | PF0 | | PF1 | | PF0_VF0 | | PF0_VF1 | > > + +-----------------+ +--------------+ +-------------+ +-----------+ > > + > > +On IOFS, it introducing some enhancements compared with original DFL > design. > > +1. It introducing Port Gasket in PF0 which is responsible for FPGA > > +management, like FME and Port management. The Port Gasket contains > > +all the PR specific > > modules > > So in IOFS, in PF0, we always have FME and PORT DFH, is my understanding > correct? Yes. > Then why we need patch #3? This is for " Multiple VFs per PR slot" model, in this model, the Port device would not connected to AFU (the BarID of Port device should be set to invalid), so we just can access PR slot/AFU resource via VFs. > > Another question is in IOFS, do we need to support multiple PR regions/Ports? > If that is the case, how should we know which VFs belongs to PORT1 or PORT2? > > > +and logic, e.g., PR slot reset/freeze control, user clock, remote STP etc. > > +Architecturally, a Port Gasket can have multiple PR slots where user > > +workload > > can > > +be programmed into. > > +2. To expend the scalable of FPGA, it can support multiple FPs in > > +static region > > s/FPs/PFs/ I will fix on next version. > > > +which contain some static functions like VirtIO, diagnostic test, and > > +access over VFIO or assigned to VMs easily. Those PFs will not have a > > +Port Unit which > > without > > +PR region (AFU) connected to those PFs, and the end-user cannot > > +partial > > reconfigurate > > s/reconfigurate/reconfigure/ I will fix on next version. > > > +those PFs. > > +3. In our previous DFL design, it can only create one VF based in an > > +AFU. To > > raise > > +the efficiency usage of AFU, it can create more than one VFs in an > > +AFU via PCIe SRIOV, so those VFs share the PR region and resource. > > + > > +There is one reference architecture design for IOFS as illustrated below: > > + > > + +----------------------+ > > + | PF/VF mux/demux | > > + +--+--+-----+------+-+-+ > > + | | | | | > > + +------------------------+ | | | | > > + PF0 | +---------+ +-+ | | > > + +---+---+ | +---+----+ | | > > + | DFH | | | DFH | | | > > + +-------+ +-----+----+ +--------+ | | > > + | FME | | VirtIO | | Test | | | > > + +-------+ +----------+ +--------+ | | > > + | Port | PF1 PF2 | | > > + +---+---+ | | > > + | +----------+ | > > + | | ++ > > + | | | > > + | | PF0_VF0 | PF0_VF1 > > + | +-----------------+-----------+------------+ > > + | | +-----+-----------+--------+ | > > + | | | | | | | > > + | | +------+ | +--+ -+ +--+---+ | | > > + | | | CSR | | | DFH | | DFH | | | > > + +-----------+ +------+ | +-----+ +------+ | | > > + | | | DEV | | DEV | | | > > + | | +-----+ +------+ | | > > + | | PR Slot | | > > + | +--------------------------+ | > > + | Port Gasket | > > + +------------------------------------------+ > > + > > +Here are the major changes about DFL structures on IOFS > > +implementation > > design: > > +1. The Port Gasket connects to FIU Port in DFL, but the Next_AFU > > +pointer in FIU feature header can point to NULL so that it is no AFU > > +connects to a FIU Port. > > +2. The VF which include in PR region can start with AFU feature > > +header without a FIU Port feature header. > > What about PF2 in static region? Which type of DFH will be used? An IP designer may choose to add more than one PF for interfacing with IP on the FPGA. If at least one PF implements a DFL with management features such as an FME or PR, then the device can be managed using the IOFS software stack. For example, a design may include FME and PR on PF0 and the actual workload interfaces on PF1. If a workload implements virtio-net backend and interface, the IOFS software stack will only bind to and communicate with IOFS features/interfaces found in the DFL on PF0. The second PF, PF1, will bind with virtio-net driver presenting itself as a network interface to the OS. So the IOFS providing the diversity for IP designer. > > Thanks > Hao > > > > > Performance Counters > > ==================== > > -- > > 2.17.1
diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst index ef9eec71f6f3..6f9eae1c1697 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -58,7 +58,10 @@ interface to FPGA, e.g. the FPGA Management Engine (FME) and Port (more descriptions on FME and Port in later sections). Accelerated Function Unit (AFU) represents an FPGA programmable region and -always connects to a FIU (e.g. a Port) as its child as illustrated above. +always connects to a FIU (e.g. a Port) as its child as illustrated above, but +on IOFS design, it introducing Port Gasket which contains AFUs. For DFL perspective, +the Next_AFU pointer on FIU feature header can point to NULL so the AFU is not +connects to a FIU(more descriptions on IOFS in later section). Private Features represent sub features of the FIU and AFU. They could be various function blocks with different IDs, but all private features which @@ -134,6 +137,9 @@ reconfigurable region containing an AFU. It controls the communication from SW to the accelerator and exposes features such as reset and debug. Each FPGA device may have more than one port, but always one AFU per port. +On IOFS, it introducing a new hardware unit, Port Gasket, which contains all +the PR specific modules and regions (more descriptions on IOFS in later section). + AFU === @@ -143,6 +149,9 @@ used for accelerator-specific control registers. User-space applications can acquire exclusive access to an AFU attached to a port by using open() on the port device node and release it using close(). +On IOFS, the AFU is embedded in a Port Gasket. The AFU resource can expose via +VFs with SRIOV support (more descriptions on IOFS in later section). + The following functions are exposed through ioctls: - Get driver API version (DFL_FPGA_GET_API_VERSION) @@ -284,7 +293,8 @@ FME is always accessed through the physical function (PF). Ports (and related AFUs) are accessed via PF by default, but could be exposed through virtual function (VF) devices via PCIe SRIOV. Each VF only contains -1 Port and 1 AFU for isolation. Users could assign individual VFs (accelerators) +1 Port (On IOFS design, the VF is designs without Port) and 1 AFU for isolation. +Users could assign individual VFs (accelerators) created via PCIe SRIOV interface, to virtual machines. The driver organization in virtualization case is illustrated below: @@ -389,6 +399,91 @@ The device nodes used for ioctl() or mmap() can be referenced through:: /sys/class/fpga_region/<regionX>/<dfl-fme.n>/dev /sys/class/fpga_region/<regionX>/<dfl-port.n>/dev +Intel Open FPGA stack +===================== +Intel Open FPGA stack aka IOFS, Intel's version of a common core set of +RTL to allow customers to easily interface to logic and IP on the FPGA. +IOFS leverage the DFL for the implementation of the FPGA RTL design. + +IOFS designs allow for the arrangement of software interfaces across multiple +PCIe endpoints. Some of these interfaces may be PFs defined in the static region +that connect to interfaces in an IP that is loaded via Partial Reconfiguration (PR). +And some of these interfaces may be VFs defined in the PR region that can be +reconfigured by the end-user. Furthermore, these PFs/VFs may also be arranged +using a DFL such that features may be discovered and accessed in user space +(with the aid of a generic kernel driver like vfio-pci). The diagram below depicts +an example design with two PFs and two VFs. In this example, PF1 implements its +MMIO space such that it is compatible with the VirtIO framework. The other functions, +VF0 and VF1, leverage VFIO to export the MMIO space to an application or a hypervisor. + + +-----------------+ +--------------+ +-------------+ +------------+ + | FPGA Managerment| | VirtIO | | User App | | Virtual | + | App | | App | | | | Machine | + +--------+--------+ +------+-------+ +------+------+ +-----+------+ + | | | | + | | | | + +--------+--------+ +------+-------+ +------+------+ | + | DFL Driver | |VirtIO driver | | VFIO | | + +--------+--------+ +------+-------+ +------+------+ | + | | | | + | | | | + +--------+--------+ +------+-------+ +------+------+ +----+------+ + | PF0 | | PF1 | | PF0_VF0 | | PF0_VF1 | + +-----------------+ +--------------+ +-------------+ +-----------+ + +On IOFS, it introducing some enhancements compared with original DFL design. +1. It introducing Port Gasket in PF0 which is responsible for FPGA management, +like FME and Port management. The Port Gasket contains all the PR specific modules +and logic, e.g., PR slot reset/freeze control, user clock, remote STP etc. +Architecturally, a Port Gasket can have multiple PR slots where user workload can +be programmed into. +2. To expend the scalable of FPGA, it can support multiple FPs in static region +which contain some static functions like VirtIO, diagnostic test, and access over +VFIO or assigned to VMs easily. Those PFs will not have a Port Unit which without +PR region (AFU) connected to those PFs, and the end-user cannot partial reconfigurate +those PFs. +3. In our previous DFL design, it can only create one VF based in an AFU. To raise +the efficiency usage of AFU, it can create more than one VFs in an AFU via PCIe +SRIOV, so those VFs share the PR region and resource. + +There is one reference architecture design for IOFS as illustrated below: + + +----------------------+ + | PF/VF mux/demux | + +--+--+-----+------+-+-+ + | | | | | + +------------------------+ | | | | + PF0 | +---------+ +-+ | | + +---+---+ | +---+----+ | | + | DFH | | | DFH | | | + +-------+ +-----+----+ +--------+ | | + | FME | | VirtIO | | Test | | | + +-------+ +----------+ +--------+ | | + | Port | PF1 PF2 | | + +---+---+ | | + | +----------+ | + | | ++ + | | | + | | PF0_VF0 | PF0_VF1 + | +-----------------+-----------+------------+ + | | +-----+-----------+--------+ | + | | | | | | | + | | +------+ | +--+ -+ +--+---+ | | + | | | CSR | | | DFH | | DFH | | | + +-----------+ +------+ | +-----+ +------+ | | + | | | DEV | | DEV | | | + | | +-----+ +------+ | | + | | PR Slot | | + | +--------------------------+ | + | Port Gasket | + +------------------------------------------+ + +Here are the major changes about DFL structures on IOFS implementation design: +1. The Port Gasket connects to FIU Port in DFL, but the Next_AFU pointer in +FIU feature header can point to NULL so that it is no AFU connects to a FIU +Port. +2. The VF which include in PR region can start with AFU feature header without +a FIU Port feature header. Performance Counters ====================