Date: Tue, 9 Mar 2010 09:07:52 +0000 From: Doug Rabson <dfr@rabson.org> To: James R. Van Artsdalen <james-freebsd-current@jrv.org> Cc: David Ehrmann <ehrmann@gmail.com>, freebsd-current@FreeBSD.org, Norikatsu Shigemura <nork@FreeBSD.org>, Julian Elischer <julian@elischer.org> Subject: Re: Core i5 AES acceleration Message-ID: <89BC6265-4DB4-46A2-A01E-80FDA6E7377B@rabson.org> In-Reply-To: <4B95920C.5000909@jrv.org> References: <4B934015.8000908@gmail.com> <4B934354.4030002@elischer.org> <20100307184422.7007747d.nork@FreeBSD.org> <4B93E96B.8090002@gmail.com> <20100309080951.b1a37510.nork@FreeBSD.org> <4B95920C.5000909@jrv.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 Mar 2010, at 00:10, James R. Van Artsdalen wrote: > Norikatsu Shigemura wrote: >> According to http://en.wikipedia.org/wiki/AES-NI , we can get >> specification document: http://software.intel.com/file/20457 . >>=20 >> I saw it, and consider that we can release under BSDL. Because >> of 'from specification'. >=20 > That document is short on details, such as the opcodes and machine > implementation details (flags, etc). >=20 > The XMM registers are used. That may be a problem for kernel code. >=20 > When last I looked openssl did not use /dev/crypt - it's not clear how > big the benefit would be from doing this if nothing that uses openssl = wins. >=20 > It might be more beneficial to FreeBSD to patch openssl to use > /dev/crypt. If it turns out to not be a significant win then that = might > hint that the AES opcodes won't be significant win in general either. The in-kernel kerberos code for NFS would also benefit since it uses the = crypto framework.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89BC6265-4DB4-46A2-A01E-80FDA6E7377B>