Date: Mon, 21 Oct 2013 11:14:28 +0200 From: Andre Oppermann <andre@freebsd.org> To: jmg@funkthat.com Cc: Mark R V Murray <mark@grondar.org>, freebsd-arch@FreeBSD.org Subject: Re: always load aesni or load it when cpu supports it Message-ID: <5264F074.4010607@freebsd.org> In-Reply-To: <20131020161634.GQ56872@funkthat.com> References: <20131020070022.GP56872@funkthat.com> <423D921D-6CE5-49D9-BCED-AB14EB236800@grondar.org> <20131020161634.GQ56872@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20.10.2013 18:16, John-Mark Gurney wrote: > Mark Murray wrote this message on Sun, Oct 20, 2013 at 11:38 +0100: >> >> On 20 Oct 2013, at 08:00, John-Mark Gurney <jmg@funkthat.com> wrote: >> >>> Comments? Suggestions or ideas? >> >> I'd love to have this - /dev/random would be a lot more efficient. > > Though we don't have a common interface for this... This was one of > the issues I raised w/ the PEFS patch that was brought up recently... > > If you want to use the OpenCrypto kernel frame work, then things will > work... If you need a lower overhead interface, then you'll have to > do a lot of wrapping of the code, or copy it, which is worse... I don't think copying is necessary, even though it was done at times. The base crypto and hash algorithms are almost all under sys/crypto/ now and used by various other parts including OpenCrypto. OpenCrypto then wraps it with a work-queue style API to allow software and dedicated hardware implementations to work seamlessly. > The other question now to ask, should we make AES a first class kernel > interface and bypass the OpenCrypto framework? Or complete the work > pjd did to make the OpenCrypto framework more effecient? The problem at least in some places is the deferred processing nature inherent to OpenCrypto. For example in TCP-AO it would be a huge pain to send the work off and have it call back later when done at some random point in the future. Here I need in-line processing to completion and having AES-NI available there would certainly be helpful instead of doing it in pure software. > It does look like we already have a good number of consumers for > crypto/rijndael: geom_bde, ipsec, random and wlan_ccmp... Which > also means that they aren't making use of AES accelerator cards... Exactly. Sometimes the deferred processing model as in OpenCrypto is the right one, sometimes doing it in-place is better. None of these cases should be artificially restricted. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5264F074.4010607>