Re: af_alg benchmarks and performance

[Assaf Gordon]

Hello,

On Tue, May 08, 2018 at 02:20:07AM +0200, Bruno Haible wrote:
> The following approaches come to mind:
[...] 
>   * Use the kernel-provided meta-info about the algorithms to decide whether
>     to use the kernel API.
> 
>     In detail: Read /proc/crypto at run time. It consists of records
>     with fields (name, driver, module, priority, internal, type).
>     - Consider only the records for the names we are interested in.
>     - Eliminate records with module != "kernel" (since we are not ready to
>       handle the situation that the module gets unloaded while af_alg.c
>       iterates on the data).
>     - No need to eliminate records with internal = "yes", since these have a
>       name that starts with '__', thus are already eliminated.
>     - Eliminate records with priority <= 100, because these are the generic
>       implementations, that provide no significant speedup compared to the
>       generic C implementation in gnulib (assuming the gnulib code was 
> compiled
>       with -O2).

With these criteria, it is basically guarenteed that gnulib/coreutils will
rarely if ever use the kernel Crypto API extensions on any standard/common
distribution:
Debian/Ubuntu/CentOS/Fedora (and I assume redhat) - all have the "sha*-generic"
as built-in kernel module with priority 0, and the "sha*-ssse3"
as an external module (for x86_64). In which case, using OpenSSL's optimized
code would have been better.

Wouldn't it be better to leave the decision of using or not using
the crypto API to the distribution packagers ?
This way, if they aim for a target that is likely to benefit from
using the Crypto API, they can enable it (either knowing that the cpus
are likely to have hardware crypto, or perhaps include the
optimized crypto driveres as built-in modulels).

regards,
 - assaf