| Message ID | 1565775265-21212-1-git-send-email-zhangfei.gao@linaro.org |
|---|---|
| Headers | show |
| Series | A General Accelerator Framework, WarpDrive | expand |
On Wed, Aug 14, 2019 at 05:34:23PM +0800, Zhangfei Gao wrote: > *WarpDrive* is a general accelerator framework for the user application to > access the hardware without going through the kernel in data path. > > WarpDrive is the name for the whole framework. The component in kernel > is called uacce, meaning "Unified/User-space-access-intended Accelerator > Framework". It makes use of the capability of IOMMU to maintain a > unified virtual address space between the hardware and the process. > > WarpDrive is intended to be used with Jean Philippe Brucker's SVA > patchset[1], which enables IO side page fault and PASID support. > We have keep verifying with Jean's sva/current [2] > We also keep verifying with Eric's SMMUv3 Nested Stage patch [3] > > This series and related zip & qm driver as well as dummy driver for qemu test: > https://github.com/Linaro/linux-kernel-warpdrive/tree/5.3-rc1-warpdrive-v1 > zip driver already been upstreamed. > zip supporting uacce will be the next step. > > The library and user application: > https://github.com/Linaro/warpdrive/tree/wdprd-v1-current Do we want a new framework ? I think that is the first question that should be answer here. Accelerator are in many forms and so far they never have been enough commonality to create a framework, even GPUs with the drm is an example of that, drm only offer share framework for the modesetting part of the GPU (as thankfully monitor connector are not specific to GPU brands :)) FPGA is another example the only common code expose to userspace is about bitstream management AFAIK. I would argue that a framework should only be created once there is enough devices with same userspace API. Meanwhile you can provide in kernel helper that allow driver to expose same API. If after a while we have enough device driver which all use that same in kernel helpers API then it will a good time to introduce a new framework. Meanwhile this will allow individual device driver to tinker with their API and maybe get to something useful to more devices in the end. Note that what i propose also allow userspace code sharing for all driver that use the same in kernel helper. Cheers, Jérôme
Hi, Jerome Thanks for your suggestion On 2019/8/16 上午1:04, Jerome Glisse wrote: > On Wed, Aug 14, 2019 at 05:34:23PM +0800, Zhangfei Gao wrote: >> *WarpDrive* is a general accelerator framework for the user application to >> access the hardware without going through the kernel in data path. >> >> WarpDrive is the name for the whole framework. The component in kernel >> is called uacce, meaning "Unified/User-space-access-intended Accelerator >> Framework". It makes use of the capability of IOMMU to maintain a >> unified virtual address space between the hardware and the process. >> >> WarpDrive is intended to be used with Jean Philippe Brucker's SVA >> patchset[1], which enables IO side page fault and PASID support. >> We have keep verifying with Jean's sva/current [2] >> We also keep verifying with Eric's SMMUv3 Nested Stage patch [3] >> >> This series and related zip & qm driver as well as dummy driver for qemu test: >> https://github.com/Linaro/linux-kernel-warpdrive/tree/5.3-rc1-warpdrive-v1 >> zip driver already been upstreamed. >> zip supporting uacce will be the next step. >> >> The library and user application: >> https://github.com/Linaro/warpdrive/tree/wdprd-v1-current > Do we want a new framework ? I think that is the first question that > should be answer here. Accelerator are in many forms and so far they > never have been enough commonality to create a framework, even GPUs > with the drm is an example of that, drm only offer share framework > for the modesetting part of the GPU (as thankfully monitor connector > are not specific to GPU brands :)) > > FPGA is another example the only common code expose to userspace is > about bitstream management AFAIK. > > I would argue that a framework should only be created once there is > enough devices with same userspace API. Meanwhile you can provide > in kernel helper that allow driver to expose same API. If after a > while we have enough device driver which all use that same in kernel > helpers API then it will a good time to introduce a new framework. > Meanwhile this will allow individual device driver to tinker with > their API and maybe get to something useful to more devices in the > end. > > Note that what i propose also allow userspace code sharing for all > driver that use the same in kernel helper. > Yes, we understand it is not easy for a new framework. There are discussions in rfc2 (2018/9) and rfc3 (2018/11). To make life easier, we plan to move the uacce to driver/misc to support our own product first until it is mature. Using uacce, Currently we get quite a big performance improvement in our crypto product, like zip, hpre, sec. Our final goal is "A General Accelerator Framework", which maybe ambitious. So uacce is designed to be a common framework, can be easily supporting more accelerators. And we are happy to get more requirements and make it mature. Another good point is SVA support in ongoing, http://jpbrucker.net/sva/ After sva mature, the accelerators support will be much easier. Thanks
On Thu, Aug 15, 2019 at 01:04:24PM -0400, Jerome Glisse wrote: > Date: Thu, 15 Aug 2019 13:04:24 -0400 > From: Jerome Glisse <jglisse@redhat.com> > To: Zhangfei Gao <zhangfei.gao@linaro.org> > CC: linux-accelerators@lists.ozlabs.org, Greg Kroah-Hartman > <gregkh@linuxfoundation.org>, linux-kernel@vger.kernel.org, Arnd Bergmann > <arnd@arndb.de> > Subject: Re: [PATCH 0/2] A General Accelerator Framework, WarpDrive > User-Agent: Mutt/1.11.3 (2019-02-01) > Message-ID: <20190815170424.GA30916@redhat.com> > > On Wed, Aug 14, 2019 at 05:34:23PM +0800, Zhangfei Gao wrote: > > *WarpDrive* is a general accelerator framework for the user application to > > access the hardware without going through the kernel in data path. > > > > WarpDrive is the name for the whole framework. The component in kernel > > is called uacce, meaning "Unified/User-space-access-intended Accelerator > > Framework". It makes use of the capability of IOMMU to maintain a > > unified virtual address space between the hardware and the process. > > > > WarpDrive is intended to be used with Jean Philippe Brucker's SVA > > patchset[1], which enables IO side page fault and PASID support. > > We have keep verifying with Jean's sva/current [2] > > We also keep verifying with Eric's SMMUv3 Nested Stage patch [3] > > > > This series and related zip & qm driver as well as dummy driver for qemu test: > > https://github.com/Linaro/linux-kernel-warpdrive/tree/5.3-rc1-warpdrive-v1 > > zip driver already been upstreamed. > > zip supporting uacce will be the next step. > > > > The library and user application: > > https://github.com/Linaro/warpdrive/tree/wdprd-v1-current > > Do we want a new framework ? I think that is the first question that > should be answer here. Accelerator are in many forms and so far they > never have been enough commonality to create a framework, even GPUs > with the drm is an example of that, drm only offer share framework > for the modesetting part of the GPU (as thankfully monitor connector > are not specific to GPU brands :)) > > FPGA is another example the only common code expose to userspace is > about bitstream management AFAIK. > > I would argue that a framework should only be created once there is > enough devices with same userspace API. Meanwhile you can provide > in kernel helper that allow driver to expose same API. If after a > while we have enough device driver which all use that same in kernel > helpers API then it will a good time to introduce a new framework. > Meanwhile this will allow individual device driver to tinker with > their API and maybe get to something useful to more devices in the > end. > > Note that what i propose also allow userspace code sharing for all > driver that use the same in kernel helper. > > Cheers, > Jérôme Hi, Jerome, I explain the idea here: https://zhuanlan.zhihu.com/p/79680889. We think this is a comment requirement for eveybody. Hope this can help the discussion. Thanks -- -Kenneth(Hisilicon)