Re: Enabling AESNI by default

On Thu, 2020-12-31 at 14:09 -0800, Rodney W. Grimes wrote:
> > We've had the AESNI module for quite a few years now, and it has
> > not
> > caused any problems.
> > 
> > I am wondering if there are any objections to including it in
> > GENERIC,
> > so that users get the benefit without having to have the "tribal
> > knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC,
> > etc),
> > you need to load aesni.ko'
> > 
> > Userspace crypto that uses openssl or similar libraries is already
> > taking advantage of these CPU instructions if they are available,
> > by
> > excluding this feature from GENERIC we are just causing the "out of
> > the
> > box" experience to by very very slow for crypto.
> > 
> > For example, writing 1MB blocks to a GELI encrypted swap-backed
> > md(4)
> > device:
> > 
> > with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 _at_ 2.20GHz
> > 
> > fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --
> > bs=1m
> > --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
> > --group_reporting --fallocate=none --runtime=60 --time_based
> > 
> > 
> > stock:
> > write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
> > 
> > with aesni.ko loaded:
> > write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
> > 
> > 
> > Does anyone have a compelling reason to deny our users the 5x
> > speedup?
> 
> Its for ever dead code on a large number of machines that do not have
> the hardware for it.  I know that is a decreasing set, but imho it
> would be better to somehow ONLY load the module if you had CPU
> support for it.  The down side is that detection would probably have
> to be in the laoder as this code can be used very early on.
> 

Not nearly so much as the code to support the PC/AT RTC and i8254
hardware as kernel eventtimers is dead code, probably today on
virtually every x86 machine that runs freebsd.

In other words, if you want to start worrying about mostly-unused code,
aesni is not the place to start.

-- Ian