From owner-freebsd-current@freebsd.org Fri Dec 21 08:46:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEBAB134202A for ; Fri, 21 Dec 2018 08:46:55 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 17E368CD80 for ; Fri, 21 Dec 2018 08:46:55 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: by mailman.ysv.freebsd.org (Postfix) id C09631342029; Fri, 21 Dec 2018 08:46:54 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96E361342027 for ; Fri, 21 Dec 2018 08:46:54 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18BA08CD7F for ; Fri, 21 Dec 2018 08:46:53 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from [84.237.50.47] (helo=regency.nsu.ru) by mx.nsu.ru with esmtp (Exim 4.72) (envelope-from ) id 1gaGSH-0008WI-GD for current@freebsd.org; Fri, 21 Dec 2018 15:46:49 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id wBL9Gijb056885 for ; Fri, 21 Dec 2018 15:16:44 +0600 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id wBL9Gdll056846 for current@freebsd.org; Fri, 21 Dec 2018 16:16:39 +0700 (+07) (envelope-from danfe) Date: Fri, 21 Dec 2018 16:16:39 +0700 From: Alexey Dokuchaev Cc: FreeBSD Current Subject: Re: AESNI, /dev/crypto, and new OpenSSL Message-ID: <20181221091639.GA53513@regency.nsu.ru> References: <20181220173535.GA2505@regency.nsu.ru> <20181220181007.GA2374@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181220181007.GA2374@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i X-KLMS-Rule-ID: 3 X-KLMS-Message-Action: skipped X-KLMS-AntiSpam-Status: not scanned, whitelist X-KLMS-AntiPhishing: not scanned, whitelist X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, not scanned, whitelist X-Rspamd-Queue-Id: 18BA08CD7F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.96)[-0.961,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-Mailman-Approved-At: Fri, 21 Dec 2018 11:25:16 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 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: Fri, 21 Dec 2018 08:46:56 -0000 On Fri, Dec 21, 2018 at 01:10:07AM +0700, Alexey Dokuchaev wrote: > On Thu, Dec 20, 2018 at 09:33:41AM -0800, Freddie Cash wrote: > > On Thu, Dec 20, 2018 at 9:21 AM Alexey Dokuchaev wrote: > > > Had something got broken here, or I'm misunderstanding how this machinery > > > now works? > > > > Start reading here: > > > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090195.html > > > > That thread covers this issue. :) Along with the "fix" for it. > > Thanks for the pointer. I've checked both -current and -hackers MLs prior > to posting, but didn't expect this would show up on -stable first. :) In case people find this thread and want quick answers without having to deviate to -stable, here's a quick summary and my speed test results, with some quotes from delphij@, jhb@, et al.: 1) aesni(4) and crypto[dev](4) modules are not required now for OpenSSL, and userland acceleration in general, to work; 2) On capable systems, AES-NI would be used automatically. In fact, it's much faster to use the AES-NI instructions in userland than to use a system call that copies the data into a kernel buffer, uses the same AES-NI instructions, then copies the data back out again along with the overhead of a pair of user <--> kernel transitions. (Note from me: if you've observed very strange results when using -evp with aesni(4) + BSD cryptodev engine on OpenSSL 1.0.2, it was probably because of that user <--> kernel multicopying.) Some quick naive benchmarks on AMD A8-5550M APU (results were trimmed for brevity): baseline: openssl speed -elapsed aes-128-cbc: 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes 35922.35k 39346.28k 40492.29k 94625.81k 95194.36k 95619.24k hardware extensions: openssl speed -elapsed -evp aes-128-cbc 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes 133823.08k 186960.39k 226363.05k 238189.15k 241782.56k 241646.38k AES-NI disabled: env OPENSSL_ia32cap="~0x200000000000000" openssl speed -elapsed -evp aes-128-cbc: 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes 54820.92k 64884.98k 69229.02k 70424.31k 70731.22k 70714.02k It's interesting how -evp run w/o AES-NI got capped at ~67 GB/s, while the baseline had sustained at ~91 GB/s. AES-NI run had reached pretty solid ~230 GB/s. ./danfe