From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7DF2DC02193 for ; Mon, 3 Feb 2025 10:13:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1352E280010; Mon, 3 Feb 2025 05:13:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BF21280002; Mon, 3 Feb 2025 05:13:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA105280010; Mon, 3 Feb 2025 05:13:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C567E280002 for ; Mon, 3 Feb 2025 05:13:31 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 40B958247F for ; Mon, 3 Feb 2025 10:13:31 +0000 (UTC) X-FDA: 83078221422.17.D0CD527 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf17.hostedemail.com (Postfix) with ESMTP id 6D5D540007 for ; Mon, 3 Feb 2025 10:13:28 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf17.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738577609; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YBv2sb4iWW41msmutVjIBlxq+3M2KFUxbM4psyXFmCw=; b=Xv8r6MP7JhNeDc9JTuOFsaLjW9rcUvzsC+ZwHcdlBLsnfdfzybk/V2crzwyLvCEx99ZCZv fYZb1hyMKCwj6hkQvGd76eySkALB0ptQ4Q8LdJ9TAZUKimYBtCgJlzHVBJHlfEqBVe8Mpr DNmiy3zbBgbtBy3TH21vY9LYDNj8rOU= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf17.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738577609; a=rsa-sha256; cv=none; b=fZkMUcD/6jV9gyQ0VHJbuTpdBtq+xtX4P47Y87yWt6XtuDLg5nJ4ERWLIk4mPYjdgK3Pnc Y9g98/1gtQwDIQDNquAUsqy4/ftGujcHQEzSwxV4vpQisyFCO8kwMFVkwwV8C3MlHyDnFo +7sVBcROiPK5PAXcgI3sKvvRaoyWy3I= Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Ymj1n6fV9z6L4yZ; Mon, 3 Feb 2025 18:10:53 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 8732D140A34; Mon, 3 Feb 2025 18:13:25 +0800 (CST) Received: from localhost (10.203.177.66) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 3 Feb 2025 11:13:24 +0100 Date: Mon, 3 Feb 2025 10:13:23 +0000 From: Jonathan Cameron To: Wei Huang CC: , , Don Dutile , Joel Savitz , "Moyes, William" , "Iyer, Shyam" , "Lynch, Nathan" , , , "Suthikulpanit, Suravee" , , , Zhangfei Gao , Zhou Wang , Shameer Kolothum , Jason Gunthorpe Subject: Re: [LSF/MM/BPF TOPIC] Enabling Smart Data Stream Accelerator Support for Linux Message-ID: <20250203101323.00001e6e@huawei.com> In-Reply-To: References: X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.177.66] X-ClientProxiedBy: lhrpeml500005.china.huawei.com (7.191.163.240) To frapeml500008.china.huawei.com (7.182.85.71) X-Rspamd-Queue-Id: 6D5D540007 X-Stat-Signature: 4s8zfn1tke4e5yskj9s7warhjuk6p3rb X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1738577608-214056 X-HE-Meta: U2FsdGVkX1+4Kck9eRAPPKp20OHvbd0RmyoCEqCNQ9tgMJh5w+7JhSB/9lSoeWqkI8125OZQSBfSCSTq4ndQpPeh/a0A6KyiNso5FDnxW6L0pYv02NTAwVw32SoWHsg6dnpnW6IzIiCIORCz+GLy/xRA0WPuZK+OHUrMIMaHWmQz7Vzo286NCCvDpCYeAfN9VUQCx5DuZBsVyF9JyIKNOM5jNxQe/UvJhFvucwmFCnW8IHjy97CMij/gkBriObv2z6YqszSlChxgtCqh6+KIY6HlL66V3VKKQpGsvQpM8ztJMLtaFkWZw15AlJz/cq/SB6WdBylBgTkXABoKkMLZ0pqc1qpZD1FFPyfDrsgYY5YbxnnT+txWajZmGonYJ8Zeib5gqxdtQL1fDjjfWIYXfRH5uyh275/nZA4qeXQD8LfBiW6to9OGvWcVcklT1p0TpUtXnLXXJ/FEOyRBP9ed9WL137sE89iagM81vjaVzOk5L/CbJtWyj7l+5jVy9s1aPKiA+Rxieenv4sNFifrUzBT9W/CzRfTXxeCdIFb3H7NbMIXaTn+idrncX1CbAXXqwUPBALwkApIk+RI1T+gej3CSPQVzJcMP9HHkoTkWguOzVgBSUZC+0DrFu4VHxBRbbtuTmrTnom4rBoghb/42/Wg7gZ5Nh+9bWypHnumkpshBaQp2kMVIP3dtu3dppuRIwJgQTKHTJbSWqEvECsHrH0EBwsZPTTjAOpvf9q77G5iT6lXOyqnkYdavTZPH932nTbVXt2NjVFBs80yFU9yks6TvPtwZbznh3G16F+cPFf6HfRG/eoBLNQ5E/KbpRPdODtJb/BowAElJJk+a5mqa0uE2N2s/l4WtrlWGHJH600WbgF3pTsgvDJtnDAT2pBWSUkEnJ4M7BakSiaE51Eiw4GfytrsJtH/KZn4oG1h7qxP2/WCZqJwmiCw98VhUedCYQPsS69T+jfLURDojOSZ OxvaRhWH +Ew+Y+H3ogNIUyqPO8iyu7qC53WKpPT0/86nGXCKpQvlwtiXPxP2PAD4tIHt1dHlnpAdt1yLt6fNDmiJL+tVPco1aJ/jKkpnNGXPeqAhbgJUoUuinIxTLgiApWBWP4x/5VZY+9GzUCY2WoyTYGMQ3ykdknmDRVLBrHSz/iEq9SAN7psWVFiWvg90Y7F8cVX57pGZJV3j/q4X00n9F6Ru3vTkssYXT/pEgrOFX7cJegh9r6+MUL3oZmRBeNb/chZ7hX811YVnpLUa2ZiEEr/zbeTBi/EGMKZ5GrU+zT5zyl5wBLdf2g0tO0trnzV9fx2ksd7j/AeAxXwIWyh3h1+fXRFhjF4ZYfICGT2fH X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 31 Jan 2025 11:53:07 -0600 Wei Huang 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: Hi Wei, Lots of topics and hints at interesting areas, but I'd like to see more details to understand how this maps to other data moving / reorganizing accelerators. Whilst SDXI looks like a good and feature rich spec, I'm curious what is fundamentally new? Perhaps it is just the right time to improve functionality for DMA engines in general. > > 1) Use Cases > * Linux DMA engine > * Kernel task offloading (e.g., bulk copying) > * QoS and kernel perf integration > * New use cases All interesting topics across this particular DMA engine and many others. For new use cases are you planning to bring some, or is this a request for suggestions? > > 2) User-Space API Interface > * IOCTL proposal I'm curious on this aspect and how it compares with previous approaches. Obviously bring some new operators and possibly need to target remote memory. However we have existing support for userspace access to accelerators for crypto, compression etc (and much broader) We went through a similar process finding a path to support those a few years ago and ended up with UACCE. (drivers/misc/uacce lots of stuff under drivers crypto). If there is overlap it would be good to figure out a path that reduces duplication / complexity of interfacing with the various userspace projects we all care about. I won't tell the stories of pain an redesigns it took to get UACCE upstream, but if you are doing another new thing, good luck! (+CC some folk more familiar and active in this space than I am). > * Security control > * User-space app integration > > 3) Virtualization Support > * Progress & current status Good to have some more detail on this in particular. Is this mostly blocked on vSVA, IOMMUFD etc progress or is there something new? > * Challenges > > == REFERENCES == > [1] SDXI 1.0 specification, https://www.snia.org/sdxi > [2] SDXI device driver, https://github.com/AMDESE/linux-sdxi > > Thanks, > -Wei > Thanks, Jonathan >