Messages in this thread | | | Subject | Re: [PATCH 0/2] A General Accelerator Framework, WarpDrive | From | zhangfei <> | Date | Tue, 20 Aug 2019 22:26:30 +0800 |
| |
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
| |