From: Corentin LABBE <clabbe@baylibre.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-crypto@vger.kernel.org
Subject: Re: [RFC PATCH] crypto: remove CONFIG_CRYPTO_STATS
Date: Wed, 28 Feb 2024 21:37:00 +0100 [thread overview]
Message-ID: <Zd-ZbEQZEGU7sWbY@Red> (raw)
In-Reply-To: <20240223090334.167519-1-ebiggers@kernel.org>
Le Fri, Feb 23, 2024 at 01:03:34AM -0800, Eric Biggers a écrit :
> From: Eric Biggers <ebiggers@google.com>
>
> Remove support for the "Crypto usage statistics" feature
> (CONFIG_CRYPTO_STATS). This feature does not appear to have ever been
> used, and it is harmful because it significantly reduces performance and
> is a large maintenance burden.
>
> Covering each of these points in detail:
>
> 1. Feature is not being used
>
> Since these generic crypto statistics are only readable using netlink,
> it's fairly straightforward to look for programs that use them. I'm
> unable to find any evidence that any such programs exist. For example,
> Debian Code Search returns no hits except the kernel header and kernel
> code itself and translations of the kernel header:
> https://codesearch.debian.net/search?q=CRYPTOCFGA_STAT&literal=1&perpkg=1
>
> The patch series that added this feature in 2018
> (https://lore.kernel.org/linux-crypto/1537351855-16618-1-git-send-email-clabbe@baylibre.com/)
> said "The goal is to have an ifconfig for crypto device." This doesn't
> appear to have happened.
>
> It's not clear that there is real demand for crypto statistics. Just
> because the kernel provides other types of statistics such as I/O and
> networking statistics and some people find those useful does not mean
> that crypto statistics are useful too.
>
> Further evidence that programs are not using CONFIG_CRYPTO_STATS is that
> it was able to be disabled in RHEL and Fedora as a bug fix
> (https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2947).
>
> Even further evidence comes from the fact that there are and have been
> bugs in how the stats work, but they were never reported. For example,
> before Linux v6.7 hash stats were double-counted in most cases.
>
> There has also never been any documentation for this feature, so it
> might be hard to use even if someone wanted to.
>
> 2. CONFIG_CRYPTO_STATS significantly reduces performance
>
> Enabling CONFIG_CRYPTO_STATS significantly reduces the performance of
> the crypto API, even if no program ever retrieves the statistics. This
> primarily affects systems with large number of CPUs. For example,
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039576 reported
> that Lustre client encryption performance improved from 21.7GB/s to
> 48.2GB/s by disabling CONFIG_CRYPTO_STATS.
>
> It can be argued that this means that CONFIG_CRYPTO_STATS should be
> optimized with per-cpu counters similar to many of the networking
> counters. But no one has done this in 5+ years. This is consistent
> with the fact that the feature appears to be unused, so there seems to
> be little interest in improving it as opposed to just disabling it.
>
> It can be argued that because CONFIG_CRYPTO_STATS is off by default,
> performance doesn't matter. But Linux distros tend to error on the side
> of enabling options. The option is enabled in Ubuntu and Arch Linux,
> and until recently was enabled in RHEL and Fedora (see above). So, even
> just having the option available is harmful to users.
>
> 3. CONFIG_CRYPTO_STATS is a large maintenance burden
>
> There are over 1000 lines of code associated with CONFIG_CRYPTO_STATS,
> spread among 32 files. It significantly complicates much of the
> implementation of the crypto API. After the initial submission, many
> fixes and refactorings have consumed effort of multiple people to keep
> this feature "working". We should be spending this effort elsewhere.
>
Hello
I need to acknowledge that I am very probably the only one user of this.
I wished to have done more and better, but this is clearly a fail.
I am sorry and you can remove all of this.
Acked-by: Corentin Labbe <clabbe@baylibre.com>
Regards
next prev parent reply other threads:[~2024-02-28 20:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 9:03 [RFC PATCH] crypto: remove CONFIG_CRYPTO_STATS Eric Biggers
2024-02-23 12:37 ` Ard Biesheuvel
2024-02-28 20:37 ` Corentin LABBE [this message]
2024-03-01 10:37 ` Herbert Xu
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=Zd-ZbEQZEGU7sWbY@Red \
--to=clabbe@baylibre.com \
--cc=ebiggers@kernel.org \
--cc=linux-crypto@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox