Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC

[Linus Walleij <linusw@kernel.org>]

On Fri, Feb 6, 2026 at 11:08 AM wangyushan <wangyushan12@huawei.com> 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