Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Enabling Smart Data Stream Accelerator Support for Linux

[Dan Williams <dan.j.williams@intel.com>]

Wei Huang via Lsf-pc wrote:
> Hi All,
> 
> I want to proposal a talk for the LSFMMBPF conference: Enabling Smart 
> Data Stream Accelerator (SDXI) Support for Linux.
> 
> The smart data stream accelerator (SDXI) is an industry standard [1] 
> that provides various advanced capabilities, such as offloading DMA 
> operations, supporting user-space addresses, and offering other advanced 
> data processing features. With the integration of SDXI into a SoC, DMA 
> offloading can now be supported across different address spaces. This 
> talk focuses on a software design which enables comprehensive SDXI 
> support across multiple software layers in the Linux Kernel. These 
> interfaces not only facilitate SDXI hardware management but also allow 
> kernel space subsystems and user space applications to directly own and 
> control SDXI hardware under the protection of IOMMU.
> 
> To illustrate the practical applications of SDXI, Red Hat and AMD 
> developed a user-space library that leverages the SDXI driver interface, 
> demonstrating various use cases, such as memory operation offloading, in 
> both bare-metal and virtual environments.
> 
> The prototype device driver [2] and user-space library are available for 
> testing. We continue to work on the improvement of both components and 
> plan to upstream the device driver soon.
> 
> == DISCUSSION ==
> At this conference, we plan to discuss with the community on:
> 
> 1) Use Cases
> * Linux DMA engine

Is this a use case?

In other words copy-offload engines have struggled for more than a
decard to impact kernel use cases due to the maintenance burden of split
async / synchronous paths for kernel-buffer-to-kernel-buffer copies. The
Linux dmaengine subsystem mainly stayed relevant due to device-DMA use
cases. 

> * Kernel task offloading (e.g., bulk copying)
> * QoS and kernel perf integration
> * New use cases

I think for this effort to be successful it needs to focus on one
embarassingly clear use case where CPU copy hits a scaling wall, not a
gallery of potential use cases.

> 2) User-Space API Interface
> * IOCTL proposal
> * Security control
> * User-space app integration

The best API for copy-offload is no new API, i.e. transparent
acceleration of existing software. For example, io_uring is already
asking applications to rewrite and submit bulk work to the kernel. It
would be lovely if the applications got copy offload for free after
paying the io_uring conversion cost.