Hi, Olof
On 2019/8/8 下午6:41, Olof Johansson wrote:
On Thu, Aug 8, 2019 at 11:20 AM Zhangfei Gao <zhangfei.gao@xxxxxxxxxx> 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
https://github.com/Linaro/linux-kernel-warpdrive/blob/5.3-rc1-warpdrive-rc4/drivers/misc/uacce/dummy_drv/dummy_wd_dev.c
We also has an actual driver in upstreaming: hisilicon zip using uacce
https://github.com/Linaro/linux-kernel-warpdrive/blob/5.3-rc1-warpdrive-rc4/drivers/crypto/hisilicon/qm.c
The upstream is on-going, and support uacce is the next step.
https://lkml.org/lkml/2019/8/2/198.
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.
https://github.com/Linaro/warpdrive/tree/wdprd-v1-current
Regarding device-specific resource arbitration, do you have any
requirement, maybe we can work together.
Currently our target is mainly on crypto.
Thanks
