Date: Thu, 28 Jan 2016 10:43:49 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Stanislav Sedov <stas@FreeBSD.org> Cc: Alan Somers <asomers@FreeBSD.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: aesni doesn't play nice with krb5 Message-ID: <20160128084349.GJ74231@kib.kiev.ua> In-Reply-To: <F9B17F79-93B0-4648-8BBF-827BD26FA420@FreeBSD.org> References: <CAOtMX2hxYQQfx7T=unLbJUtjQ2hmHHt5Dgu7E5q9EWCegh9OQQ@mail.gmail.com> <F9B17F79-93B0-4648-8BBF-827BD26FA420@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 27, 2016 at 06:21:11PM -0800, Stanislav Sedov wrote: > > > On Jan 27, 2016, at 3:55 PM, Alan Somers <asomers@FreeBSD.org> wrote: > > > > I'm experimenting with Kerberized NFS, but my performance sucks when I > > use krb5p. I tracked the problem down to an interaction between aesni > > and krb5: aes_set_key in kcrypto_aes.c registers for a crypto session > > and requests support for two algorithms: CRYPTO_SHA1_HMAC and > > CRYPTO_AES_CBC. aesni(4) supports the latter, but not the former. So > > crypto_select_driver returns cryptosoft and krb5 uses software for > > both algorithms. > > > > It's too bad that aesni doesn't support SHA1, but other software like > > OpenSSL deals with it by using hardware for AES and software for SHA1. > > It seems to me like krb5 could be made to do the same by registering > > for two sessions, one for each algorithm. In fact, it seems like it > > would be pretty easy to do. The changes would probably be confined > > strictly to crypto_aes.c. Is there any reason why this wouldn't work? > > > > This sounds great to me. Might be worth checking with the upstream > Heimdal project to see if they might have some suggestions. But we > can definitely apply this change locally in FreeBSD as we're probably > affected by this more than other Heimdal consumers (who do not rely on > encryption that much). > Could somebody clarify whether the session initiator is the code from user or kernel space ? My note is that utilizing AESNI through /dev/crypto is useless, the syscall overhead and kernel bookkeeping eats so much time that even software AES implementations are faster than AESNI through /dev/crypto.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160128084349.GJ74231>