Re: Enabling AESNI by default

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

-- 
Rod Grimes                                                 rgrimes_at_freebsd.org