On Wed, Feb 12, 2025 at 10:33:04PM -0800, Eric Biggers wrote: > > I've already covered this extensively, but here we go again. First there are > more users of shash than ahash in the kernel, since shash is much easier to use > and also a bit faster. There is nothing storage specific about it. You've > claimed that shash is deprecated, but that reflects a misunderstanding of what > users actually want and need. Users want simple, fast, easy-to-use APIs. Not > APIs that are optimized for an obsolete form of hardware offload and have > CPU-based crypto support bolted on as an afterthought. The ahash interface was not designed for hardware offload, it's exactly the same as the skcipher interface which caters for all users. The shash interface was a mistake, one which I've only come to realise after adding the corresponding lskcipher interface. > Second, these days TLS and IPsec usually use AES-GCM, which is inherently > parallelizable so does not benefit from multibuffer crypto. This is a major > difference between the AEADs and message digest algorithms in common use. And > it happens that I recently did a lot of work to optimize AES-GCM on x86_64; see > my commits in v6.11 that made AES-GCM 2-3x as fast on VAES-capable CPUs. Bravo to your efforts on improving GCM. But that does not mean that GCM is not amenable to parallel processing. While CTR itself is obviously already parallel, the GHASH algorithm can indeed benefit from parallel processing like any other hashing algorithm. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
