[PATCH 0/2] A General Accelerator Framework, WarpDrive

[zhangfei]

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