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

zhangfei zhangfei.gao at linaro.org
Fri Aug 9 12:23:56 AEST 2019

Hi, Olof

On 2019/8/8 下午6:41, Olof Johansson wrote:
> On Thu, Aug 8, 2019 at 11:20 AM Zhangfei Gao <zhangfei.gao at linaro.org> 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-rc4
>> The library and user application:
>> https://github.com/Linaro/warpdrive/tree/wdprd-v1-current
> Hi,
> An overall comment: This isn't really an "accelerator framework" as
> much as a library for drivers to implement shared device/userspace
> memory regions where the hardware allows for it. In particular, it
> doesn't handle device-specific resource arbitration and
> (understandably) the other components needed for an actual driver.
> As such, it probably doesn't belong in drivers/misc per se, since it
> is more of a library to be used *by* drivers. It also doesn't fulfill
> the requirement of in-kernel interfaces having user when added, i.e. a
> real driver submitted that makes use of this library and implements
> the corresponding control path.

Thanks for your quick comments.

We have a simple dummy driver as en example, which can be tested in qemu

We also has an actual driver in upstreaming: hisilicon zip using uacce
The upstream is on-going, and support uacce is the next step.

Still many others drivers (crypto) using uacce, like hpre, sec, which 
plan to be upstreamed  after uacce.
With uacce, the performance improves quite a lot.

The user application depend on uacce is also in developing, which 
supports zlib and openssl now.


Regarding device-specific resource arbitration, do you have any 
requirement, maybe we can work together.
Currently our target is mainly on crypto.


More information about the Linux-accelerators mailing list