[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181005184001.GA10106@zx2c4.com>
Date: Fri, 5 Oct 2018 20:40:03 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: ard.biesheuvel@...aro.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-crypto@...r.kernel.org,
davem@...emloft.net, gregkh@...uxfoundation.org, sneves@....uc.pt,
luto@...nel.org, jeanphilippe.aumasson@...il.com,
linux@...linux.org.uk, linux-arm-kernel@...ts.infradead.org,
peter@...ptojedi.org, djb@...yp.to
Subject: Re: [PATCH net-next v6 19/23] zinc: Curve25519 ARM implementation
Hey Dan,
On Fri, Oct 05, 2018 at 03:05:38PM -0000, D. J. Bernstein wrote:
> Of course, there are other ARM microarchitectures, and there are many
> cases where different microarchitectures prefer different optimizations.
> The kernel already has boot-time benchmarks for different optimizations
> for raid6, and should do the same for crypto code, so that implementors
> can focus on each microarchitecture separately rather than living in the
> barbaric world of having to choose which CPUs to favor.
I've been playing a bit with some code to do this sort of thing,
choosing a set of implementations to enable or disable by trying all the
combinations, and then calculating a quick median. I don't know if I'll
submit that for the initial merge of this patchset -- and in fact all
the current implementations I'm proposing are pretty much okay on
microarchitectures -- but down the line this could be useful as a
mechanism.
Jason
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists