Hi, -----Original Message----- From: Xu, Rosen <rosen...@intel.com> Sent: Monday, January 25, 2021 18:33 To: Yigit, Ferruh <ferruh.yi...@intel.com>; Huang, Wei <wei.hu...@intel.com>; dev@dpdk.org; Zhang, Qi Z <qi.z.zh...@intel.com> Cc: sta...@dpdk.org; Zhang, Tianfei <tianfei.zh...@intel.com>; Ray Kinsella <m...@ashroe.eu> Subject: RE: [dpdk-stable] [PATCH v11 1/4] raw/ifpga: add fpga rsu function
Hi, > -----Original Message----- > From: Ferruh Yigit <ferruh.yi...@intel.com> > Sent: Monday, January 25, 2021 18:01 > To: Huang, Wei <wei.hu...@intel.com>; dev@dpdk.org; Xu, Rosen > <rosen...@intel.com>; Zhang, Qi Z <qi.z.zh...@intel.com> > Cc: sta...@dpdk.org; Zhang, Tianfei <tianfei.zh...@intel.com>; Ray > Kinsella <m...@ashroe.eu> > Subject: Re: [dpdk-stable] [PATCH v11 1/4] raw/ifpga: add fpga rsu > function > > On 1/22/2021 2:18 AM, Huang, Wei wrote: > > <Please do not top post, your comment moved below> > > >> > >> -----Original Message----- > >> From: Ferruh Yigit <ferruh.yi...@intel.com> > >> Sent: Friday, January 22, 2021 00:30 > >> To: Huang, Wei <wei.hu...@intel.com>; dev@dpdk.org; Xu, Rosen > >> <rosen...@intel.com>; Zhang, Qi Z <qi.z.zh...@intel.com> > >> Cc: sta...@dpdk.org; Zhang, Tianfei <tianfei.zh...@intel.com>; Ray > >> Kinsella <m...@ashroe.eu> > >> Subject: Re: [dpdk-stable] [PATCH v11 1/4] raw/ifpga: add fpga rsu > >> function > >> > >> On 1/21/2021 6:03 AM, Wei Huang wrote: > >>> RSU (Remote System Update) depends on secure manager which may be > >>> different on various implementations, so a new secure manager > >>> device is implemented for adapting such difference. > >>> There are three major functions added: > >>> 1. ifpga_rawdev_update_flash() updates flash with specific image file. > >>> 2. ifpga_rawdev_stop_flash_update() aborts flash update process. > >>> 3. ifpga_rawdev_reload() reloads FPGA from updated flash. > >>> > >>> Signed-off-by: Wei Huang <wei.hu...@intel.com> > >>> Acked-by: Tianfei Zhang <tianfei.zh...@intel.com> > >>> Acked-by: Rosen Xu <rosen...@intel.com> > >> > >> <...> > >> > >>> @@ -76,4 +76,9 @@ int > >>> ifpga_unregister_msix_irq(enum ifpga_irq_type type, > >>> int vec_start, rte_intr_callback_fn handler, void *arg); > >>> > >>> +int ifpga_rawdev_update_flash(struct rte_rawdev *dev, const char > >>> +*image, uint64_t *status); int > >>> +ifpga_rawdev_stop_flash_update(struct rte_rawdev *dev, int > >>> +force); int ifpga_rawdev_reload(struct rte_rawdev *dev, int type, > >>> +int page); > >>> + > >>> #endif /* _IFPGA_RAWDEV_H_ */ > >>> > >> > >> Hi Wei, > >> > >> Please help me understand the rawdev, who should be calling the > >> above > newly added functions? > >> > > > > Hi Ferruh, > > > > Cyborg is an OpenStack project that aims to provide a general > purpose management framework for acceleration resources (i.e. various > types of accelerators such as GPU, FPGA, NP, ODP, DPDK/SPDK and so on). > > > > To update the FPGA flash is one of requirements from Cyborg. > Originally there are no such interfaces, so I added them. > > > > These interfaces use rte_rawdev to identify which FPGA to access, > they will be called in opae_update_flash(), > > opae_cancel_flash_update() and > opae_reboot_device() in ifpga_opae_api.c . > > > > These opae_xxx function use PCI address to identify FPGA instead of > rte_rawdev, so the caller has no need to know the existence of rte_rawdev. > > In fact, Cyborg is Python application, these opae_xxx functions > will be eventually wrapped in a Python module for Cyborg to call. > > > > Thanks for clarification, I see what you are doing, but still I think > these APIs are not belong to a driver, they look like more application level. > > @Wei, @Rosen, what do you think to keep only generic raw/ipfga APIs in > the driver and move all 'ifpga_opae_api.c/h' to the sample application? @Huang, Wei, could you classify which functions are only used in sample application? All the opae_xxx functions used in sample application will be used by Cyborg. I will try to move ifpga_opae_api.c/h to sample according to Ferruh's comments. > In that case raw/ifpga APIs still can get the port_id as parameter, > and the 'opae' layer in the sample can do the conversion?
