[PATCH 0/2] A General Accelerator Framework, WarpDrive
zhangfei.gao at linaro.org
Wed Aug 21 00:26:30 AEST 2019
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, which enables IO side page fault and PASID support.
>> We have keep verifying with Jean's sva/current 
>> We also keep verifying with Eric's SMMUv3 Nested Stage patch 
>> This series and related zip & qm driver as well as dummy driver for qemu test:
>> zip driver already been upstreamed.
>> zip supporting uacce will be the next step.
>> The library and user application:
> 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
> 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
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.
More information about the Linux-accelerators