From owner-freebsd-current@freebsd.org Thu Dec 31 22:46:19 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 4F7E64D28A3 for ; Thu, 31 Dec 2020 22:46:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 4D6NYR0X8rz4T7L for ; Thu, 31 Dec 2020 22:46:18 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1609454777; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=WBFe9R/+d/3ZcQMaMsIdhbU0K6IOBl5GctTuTFyiWIoV+Dil8n0cf+gicOkfl5MyGALg99nq852F4 1dNTBlf/d1x5qjkASv6NwDRenuUzYzElkDg3tzauCHJxFOEaONc8tYTBHJqPO2/aQag5pCJF3NN/68 MbX42ke/nJPXgAT9vFXLFT9CXAJ11U9cVIWqpaJYLCdWuU2lcDfPuUSu4UXk+aphV28IhNP2W73WnS iuP3/GjfViOxA2F5+utIkMON6FxAA9HVn/gqETpMFzPoc2qTBPlw23a+XgHssfs2saS6D+Y6LLlZnQ r37Z0jw5HBdcszwIf5R++nMfUKyxa0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=2zzJnPJiu8eG9XYoNgNglD2f+EscDdXk9MvCnv/0NHA=; b=dq6FF37cSRZUdUhYZkoDWLZlgiQS7dJR9p+TSVYHr1W4sxFDLN7P6p0GRX7lAtUzDQBoj6WmLLN8d BxHtl8FBx6KpPH8BY2A/JrFBDKHFN53vOPmMh8Qj+eSZ7IVBBj0acY75YGPknODAcYPxdZvjlzZxuX JAUEBcqg3jZdIMAb5wUeyirIZWlhJLYKIByrJuOT40oOFexem1uLAKfHcdsFAg408s/8fEKl4PpN4F xwEsqudUuokj+nyfeDFtALQWdrcyujzqPLnvr/MIv8a+vnjzXX/nUSzriF6v9BfXXpumxrAqy1h06d ty6I6e9F4V1O1QEdYJY6wVLwR/TEvJg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; X-MHO-RoutePath: aGlwcGll X-MHO-User: fced9c4a-4bb9-11eb-9e76-df46ed8f892f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id fced9c4a-4bb9-11eb-9e76-df46ed8f892f; Thu, 31 Dec 2020 22:46:16 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 0BVMkEi0012466; Thu, 31 Dec 2020 15:46:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <93dd4cadbcfbe8883a72144772d713a24124c584.camel@freebsd.org> Subject: Re: Enabling AESNI by default From: Ian Lepore To: "Rodney W. Grimes" , Allan Jude Cc: FreeBSD Current Date: Thu, 31 Dec 2020 15:46:14 -0700 In-Reply-To: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net> References: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D6NYR0X8rz4T7L X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] 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 22:46:19 -0000 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 @ 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