From: Eric Biggers <ebiggers@kernel.org>
To: Simon Richter <Simon.Richter@hogyros.de>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Ard Biesheuvel <ardb@kernel.org>,
"Jason A . Donenfeld" <Jason@zx2c4.com>,
linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
sparclinux@vger.kernel.org
Subject: Re: Crypto use cases (was: Remove PowerPC optimized MD5 code)
Date: Mon, 4 Aug 2025 21:58:46 -0700 [thread overview]
Message-ID: <20250805045846.GA10695@sol> (raw)
In-Reply-To: <913e23f9-d039-4de1-a0d3-d1067dcda8ac@hogyros.de>
On Tue, Aug 05, 2025 at 01:49:31PM +0900, Simon Richter wrote:
> Hi,
>
> On 8/5/25 07:59, Eric Biggers wrote:
>
> > > md5sum uses the kernel's MD5 code:
>
> > What? That's crazy. Userspace MD5 code would be faster and more
> > reliable. No need to make syscalls, transfer data to and from the
> > kernel, have an external dependency, etc. Is this the coreutils md5sum?
> > We need to get this reported and fixed.
>
> The userspace API allows zero-copy transfers from userspace, and AFAIK also
> directly operating on files without ever transferring the data to userspace
> (so we save one copy).
>
> Userspace requests are also where the asynchronous hardware offload units
> get to chomp on large blocks of data while the CPU is doing something else:
>
> $ time dd if=test.bin of=/dev/zero bs=1G # warm up caches
> real 0m1.541s
> user 0m0.000s
> sys 0m0.732s
>
> $ time gzip -9 <test.bin >test.bin.gz # compress with the CPU
> real 2m57.789s
> user 2m55.986s
> sys 0m1.508s
>
> $ time ./gzfht_test test.bin # compress with NEST unit
> real 0m3.207s
> user 0m0.584s
> sys 0m2.487s
>
> $ time gzip -d <test.bin.nx.gz >test.bin.nx # decompress with CPU
> real 1m0.103s
> user 0m57.990s
> sys 0m1.878s
>
> $ time ./gunz_test test.bin.gz # decompress with NEST unit
> real 0m2.722s
> user 0m0.200s
> sys 0m1.872s
>
> That's why I'm objecting to measuring the general usefulness of hardware
> crypto units by the standards of fscrypt, which has an artificial limitation
> of never submitting blocks larger than 4kB: there are other use cases that
> don't have that limitation, and where the overhead is negligible because it
> is incurred only once for a few gigabytes of data.
>
> That's why I suggested changing from a priority field to "speed" and
> "overhead" fields, and calculate priority for each application as
> (size/speed+overhead) -- smallest number wins, size is what the application
> expects to use as the typical request size (which for fscrypt and IPsec is
> on the small side, so it would always select the CPU unless there was a
> low-overhead offload engine available)
>
> This probably needs some adjustment to allow selecting a low-power
> implementation (e.g. on mobile, I'd want to use offloading for fscrypt even
> if it is slower), and model request batching which reduces the overhead in a
> busy system, but it should be a good start.
What does this have to do with this thread, which is about the PowerPC
optimized MD5 code?
- Eric
next prev parent reply other threads:[~2025-08-05 4:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-03 20:44 [PATCH 0/7] MD5 library functions Eric Biggers
2025-08-03 20:44 ` [PATCH 1/7] mips: cavium-octeon: Remove Octeon optimized MD5 code Eric Biggers
2025-08-03 20:44 ` [PATCH 2/7] mips: cavium-octeon: Move octeon-crypto.c into parent dir Eric Biggers
2025-08-03 20:44 ` [PATCH 3/7] crypto: powerpc/md5 - Remove PowerPC optimized MD5 code Eric Biggers
2025-08-03 22:07 ` Segher Boessenkool
2025-08-03 22:14 ` Eric Biggers
2025-08-03 22:27 ` Segher Boessenkool
2025-08-03 22:56 ` Eric Biggers
2025-08-04 17:42 ` Christophe Leroy
2025-08-04 18:09 ` Eric Biggers
2025-08-04 19:02 ` Christophe Leroy
2025-08-04 22:59 ` Eric Biggers
2025-08-04 23:09 ` Eric Biggers
2025-08-05 6:21 ` Christophe Leroy
2025-08-05 4:49 ` Crypto use cases (was: Remove PowerPC optimized MD5 code) Simon Richter
2025-08-05 4:58 ` Eric Biggers [this message]
2025-08-05 7:17 ` Crypto use cases Simon Richter
2025-08-05 17:15 ` Eric Biggers
2025-08-05 6:27 ` [PATCH 3/7] crypto: powerpc/md5 - Remove PowerPC optimized MD5 code Christophe Leroy
2025-08-05 16:16 ` Eric Biggers
2025-08-03 20:44 ` [PATCH 4/7] crypto: sparc/md5 - Remove SPARC64 " Eric Biggers
2025-08-04 4:44 ` Simon Richter
2025-08-04 6:07 ` Eric Biggers
2025-08-03 20:44 ` [PATCH 5/7] lib/crypto: md5: Add MD5 and HMAC-MD5 library functions Eric Biggers
2025-08-03 20:44 ` [PATCH 6/7] crypto: md5 - Wrap library and add HMAC support Eric Biggers
2025-08-03 20:44 ` [PATCH 7/7] lib/crypto: tests: Add KUnit tests for MD5 and HMAC-MD5 Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250805045846.GA10695@sol \
--to=ebiggers@kernel.org \
--cc=Jason@zx2c4.com \
--cc=Simon.Richter@hogyros.de \
--cc=ardb@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.