From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3079B3A9624 for ; Fri, 6 Feb 2026 12:45:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770381911; cv=none; b=tpP1usFBDCY2vQWoCqM7In8+JYFhOS2fnvC1qxCXyN2idcbwTMJklgXvMlifYoXT3NPff1bSTMgqGOOYVtbqpHfbDCbi6kIqLUNZ3/Xf0uMlxzQD/lgk9nUOviR7mWJxdcZdpZD+qh5abmHanEioa9o3Idva1w+HRR9K8ryAPwc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770381911; c=relaxed/simple; bh=bDiq+0d3D0Yh0TtokVVa4rN0HvOe1emmSsmHz5APNsw=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gN+AkNMP7KK2GNddJASOuJpBtfTGtn9cxsKiJFdOFWVY9502n8T8KehSxhPG4p/4qTMhCjqQAD0gAqC90O+5c+sLONRzaI2MWgnDBR6gyPpsWDdvHHDDitigs16IUIXaGf/oOnxUjau5gtZJ5dt8MI+ihx0CwdR4lYUgT1K0SuA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rjMweCRT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rjMweCRT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD933C19421 for ; Fri, 6 Feb 2026 12:45:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770381910; bh=bDiq+0d3D0Yh0TtokVVa4rN0HvOe1emmSsmHz5APNsw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=rjMweCRTno0pSJ62f8k8ciB28EFkW9qA4tlSMr1/7rwWQCogbpZrSH3O9iSpPWoIm iAQcYecL5Gbx7bB7zlIee9fW4Dr+qGbGPOqGzjs99SfKFRRYLRaVVbyzdjGeLTFZ3y aGjmnoWoSnV0P/Nsg0+1CPbJtC//36Mah8QUfJvXZ2VA6HYJut/BgzKq0VuDBHDwXA 9TW3YA/cDU9Src+lf5/R0b39Xuoga4qZouCkj8eA+dqjySO2el96InH1IoPTM/vzRT /U3N4iPm95FcKbYv72BWMrGUIqiudSLLE+sFe18TOUPop2D/IwTpBaDa6N9Fi4cWZ8 QnndVrjUKa0mQ== Received: by mail-yx1-f52.google.com with SMTP id 956f58d0204a3-64ad46a44easo60507d50.0 for ; Fri, 06 Feb 2026 04:45:10 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWip4Hpvddej/Z4KbNkMMxhk633AHw7E+xSA0sOwfzLh8Vv9PLOf0qjVF5nj0x02b/BKVSIYrKmrj2asy0=@vger.kernel.org X-Gm-Message-State: AOJu0Yy3yK84HiFKpGkJrv0TKvzE7oxUumup/VmwcIticuF1gkxKmvfW lW1Zonfd2EGvSlmoold3QY0zkqIoLAykAj6rnVmBcpgdQBzgzCzsxzwuTSawv31HYmgUoo5iQeJ XHB6Lr6j9xXNrteta3dvVmtJept5udd8= X-Received: by 2002:a05:690e:d89:b0:649:f002:582b with SMTP id 956f58d0204a3-649f1e9a146mr2416290d50.7.1770381910243; Fri, 06 Feb 2026 04:45:10 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260203161843.649417-1-wangyushan12@huawei.com> <20260203161843.649417-2-wangyushan12@huawei.com> <20260204134020.00002393@huawei.com> <4c5eaf8f-2433-4971-b5d0-4f35acb2820e@huawei.com> In-Reply-To: <4c5eaf8f-2433-4971-b5d0-4f35acb2820e@huawei.com> From: Linus Walleij Date: Fri, 6 Feb 2026 13:44:59 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_QgG2qCN21qfdFqp1_uUoU1snEr_v0VrvR5O7tyuWNyeNMKM9kSQmQYe5Q4 Message-ID: Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC To: wangyushan Cc: Jonathan Cameron , alexandre.belloni@bootlin.com, arnd@arndb.de, fustini@kernel.org, krzk@kernel.org, linus.walleij@linaro.org, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, fanghao11@huawei.com, linuxarm@huawei.com, liuyonglong@huawei.com, prime.zeng@hisilicon.com, wangzhou1@hisilicon.com, xuwei5@hisilicon.com, linux-mm@vger.kernel.org, SeongJae Park , Ard Biesheuvel , herbert@gondor.apana.org.au Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 6, 2026 at 11:08=E2=80=AFAM wangyushan wrote: > Suppose we have data on SSD that need to be transferred through network. > We have technologies like DDIO and IO stash to make data flow through > L3 cache instead of DDR to avoid the influence of DDR bandwidth. [https://www.cl.cam.ac.uk/~rnw24/papers/201708-sigcomm-diskcryptnet.pdf] So as to decode, encrypt or run some AI training/inference stuff on the data, I get it. The paper immediately gives at hand a use case the Linux kernel (not userspace) could use: lock down the code and constants used by in-kernel cipher algorithms to reduce latency on encrypted disk or networks. [Added in Ard and Herbert who may be interested] Which means that if this could actually be used for these "hard kernels" in Linux the proper way to abstract this is to give the kernel a generic interface to request L3 cacheline lockdown no matter if that is employed by the kernel or userspace. > But if something is to be done to the data instead of merely copying, > and cores needs to participate, When you say this, is it "CPU cores" or others cores such as DSPs or GPU/NPUs you are thinking of, or any kind of data processing core (all of them)? This surely need to be abstracted in such a way that either of these can use it, Arnd mentions dma-buf which is a way devices think about data that the CPU cores doesn't necessarily (but may) touch, and resctrl could very well integrate into that I think. What I think is important is that the modeling in the kernel is consistent and that l3 cache lockdown is something any part of the kernel needing it can request. Yours, Linus Walleij