Re: Enabling AESNI by default

On 12/31/20 11:51 AM, Allan Jude 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?

I think this is fine.  I do hope to add AES support to ossl(4) at
some point, and it may be that ossl(4) will supplant aesni(4) (and
armv8crypto(4)) at that point, but aesni in GENERIC makes sense
right now (and I'd say to MFC it to 12).  armv8crypto in arm64
GENERIC will make sense once AES-XTS support (currently in a review)
lands.

-- 
John Baldwin