Date: Fri, 21 Dec 2018 16:16:39 +0700 From: Alexey Dokuchaev <danfe@nsu.ru> Cc: FreeBSD Current <current@freebsd.org> Subject: Re: AESNI, /dev/crypto, and new OpenSSL Message-ID: <20181221091639.GA53513@regency.nsu.ru> In-Reply-To: <20181220181007.GA2374@regency.nsu.ru> References: <20181220173535.GA2505@regency.nsu.ru> <CAOjFWZ6WB4Wgy%2BAgib%2B5OqsPxKSSfK1=_CY8VycWuHpAKe=bcw@mail.gmail.com> <20181220181007.GA2374@regency.nsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <danfe@nsu.ru> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181221091639.GA53513>