[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgp-fOSsZsYrbyzqCAfEvrt5jQs1jL-97Wc4seMNTUyng@mail.gmail.com>
Date: Sat, 29 Mar 2025 11:52:17 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [GIT PULL] Crypto Update for 6.15
On Sat, 29 Mar 2025 at 11:38, Eric Biggers <ebiggers@...nel.org> wrote:
>
> Yes. Those cases were just a single algorithm, though, so of course the library
> was simpler.
Yeah, I realize. It's the extreme case of "using the generic crypto
infrastructure is just silly to the point of being stupid".
I just think that there's a continuum of that situation.
There are cases where you *obviously* want to use the crypto
infrastructure, because you really have lots of different users, and
you actually need the flexibility (and in the extreme case you do have
the whole external async crypto engine case even if I can't for the
life of me see the point).
And there are the cases where it's just stupid to do it, because you
have one single hash you are doing and the flexibility is only pure
pointless overhead and it makes the code bigger, slower, and harder to
understand.
But I think then there are the middle grounds.
The cases where you may well just say "this is the common case that I
want to optimize for, and I know it's more efficient if I just do two
blocks in parallel and I'll do that case directly, and fall back to
the generic code for any odd cases".
Linus
Powered by blists - more mailing lists