On Mon, Oct 28, 2024 at 12:00:45PM -0700, Eric Biggers wrote:
>
> You say that your API is needed so that users don't need to "spend extra effort
> in order to accumulate and maintain multiple streams of data." That's
> incorrect, though. The users, e.g. {dm,fs}-verity, will need to do that anyway
> even with your API. I think this would have been clear if you had tried to
> update them to use your API.
It's a lot easier once you switch them back to dynamically allocated
requests instead of having them on the stack. Storing the hash state
on the stack of course limits your ability to aggregate the hash
operations since each one is hundreds-of-bytes long.
We could also introduce SYNC_AHASH_REQ_ON_STACK like we do for
skcipher but I think we should move away from that for the cases
where aggregation makes sense.
Note that when I say switching back to ahash, I'm not talking about
switching back to an asynchronous API. If you're happy with the
synchronous offerings then you're totally free to use ahash with
synchronous-only implementations, just like skcipher.
> With this patchset I am also seeing random crashes in the x86 sha256 glue code,
> and all multibuffer SHA256 hashes come back as all-zeroes. Bugs like this were
Guilty as charged. I haven't tested this at all apart from timing
the speed.
However, adding a proper test is trivial. We already have the
ahash_requests ready to go so they just have to be chained together
and submitted en-masse.
> If you're really interested in the AVX2 multibuffer SHA256 for some reason, I'd
> be willing to clean up that assembly code and wire it up to the much simpler API
> that I proposed. Despite the favorable microbenchmark result, this would be of
> limited use, for various reasons that I've explained before. But it could be
> done if desired, and it would be much simpler than what you have.
No I have zero interest in AVX2. I simply picked that because
it was already in the kernel git history and I wasn't certain
whether my CPU is recent enough to see much of a benefit from
your SHA-NI code.
Cheers,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
