From owner-freebsd-current@freebsd.org Thu Dec 31 19:51:13 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CA07A4CD1B2 for ; Thu, 31 Dec 2020 19:51:13 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [IPv6:2001:470:1:474::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6JgP3rp8z3l7C for ; Thu, 31 Dec 2020 19:51:13 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 974EF27BAE for ; Thu, 31 Dec 2020 19:51:07 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 974EF27BAE To: FreeBSD Current From: Allan Jude Subject: Enabling AESNI by default Message-ID: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> Date: Thu, 31 Dec 2020 14:51:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D6JgP3rp8z3l7C X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 19:51:13 -0000 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 @ 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? -- Allan Jude