[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231222054827.GE52600@quark.localdomain>
Date: Thu, 21 Dec 2023 23:48:27 -0600
From: Eric Biggers <ebiggers@...nel.org>
To: Jerry Shih <jerry.shih@...ive.com>
Cc: paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
herbert@...dor.apana.org.au, davem@...emloft.net,
conor.dooley@...rochip.com, ardb@...nel.org, conor@...nel.org,
heiko@...ech.de, phoebe.chen@...ive.com, hongrong.hsu@...ive.com,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-crypto@...r.kernel.org, Andy Chiu <andy.chiu@...ive.com>
Subject: Re: [PATCH v3 00/12] RISC-V: provide some accelerated cryptography
implementations using vector extensions
Hi Jerry,
On Tue, Dec 05, 2023 at 05:27:49PM +0800, Jerry Shih wrote:
> Changelog v2:
> - Turn to use simd skcipher interface for AES-CBC/CTR/ECB/XTS and
> Chacha20.
If I understand correctly, the RISC-V kernel-mode vector support now seems to be
heading down the path of supporting softirq context, as I had suggested
originally. With patches 1-2 of Andy Chiu's latest patchset
"[v7, 00/10] riscv: support kernel-mode Vector"
(https://lore.kernel.org/linux-riscv/20231221134318.28105-1-andy.chiu@sifive.com).
applied, the kernel has basic support for kernel-mode vector, including in
softirq context.
With that being the case, "skcipher" algorithms can just use the RISC-V vector
unit unconditionally, given that skcipher only supports task and softirq
context. Therefore, can you consider undoing your change that added fallbacks
using the simd helper (crypto/simd.c)? Thanks!
- Eric
Powered by blists - more mailing lists