Re: af_alg benchmarks and performance

[Bruno Haible]

What can we do to get the speedups but avoid the slowdowns, in the two
hairy cases
  - the afalg_buffer case,
  - the afalg_stream case with non-regular files?

The following approaches come to mind:

  * A "tuning" framework like the one from GMP. This is a set of benchmark
    programs that the developers use to determine the break-even points
    on a platform and write them into a platform-specific gmp-param.h file.

    Drawback: Who will have the time (and resources) to do this for the
    hundreds of x86_64 CPUs and the dozens of ARMs CPUs on the market?

  * A configure test that compares the speed of the two implementations
    and sets a flag in config.h accordingly.

    Drawbacks:
    - This does not solve the issue for programs distributed through a Linux
      distributor.
    - The outcome of this configure test may depend on the load of the machine
      at the moment 'configure' runs.
    - Changes in the kernel (which are likely to arrive due to Meltdown,
      Spectre, and Spectre-NG fixes) will affect these comparisons.
    - It goes against the goals of "reproducible builds".

  * 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).

    Drawback: Does not work if /proc is not mounted.

I would favour the third approach.

Bruno