Date: Mon, 21 Oct 2013 09:40:34 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Andre Oppermann <andre@freebsd.org> 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: <20131021164034.GU56872@funkthat.com> In-Reply-To: <5264F074.4010607@freebsd.org> References: <20131020070022.GP56872@funkthat.com> <423D921D-6CE5-49D9-BCED-AB14EB236800@grondar.org> <20131020161634.GQ56872@funkthat.com> <5264F074.4010607@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andre Oppermann wrote this message on Mon, Oct 21, 2013 at 11:14 +0200:
> 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.
Except it's not so seamless... iirc, when I was testing /dev/crypto,
it wouldn't make the software implementations available, but it does
to the kernel.. I guess this is to let the userland know it should do
the processing itself to avoid the kernel, but this just ends up making
the userland code more complicated...
Or in the case of OpenSSL and AES-NI, if you load cryptodev, it'll use
the kernel implementation of AES-NI which will always be slower than
a proper userland implementation...
> >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's not hard to provide both an async interface and a sync interface..
Does TCP-AO do AES on large blocks of data or small?
> >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.
So, right now my proposal is to teach the existing sync aes implementation
about AES-NI to get it going faster... Change the existing sync AES
(used by gbde and friends) to not allow 32 or more blocks (512
bytes) and force those needing larger block sizes to use OpenCrypto...
If we need a sync interface to OpenCrypto (and it sounds like we do), we
can provide a single call interface that does the necessary cvwait/msleep
wrapper around it... And in the AES-NI case, we could possibly decide
to run it inline, though that would be a future change...
The choice of 32 blocks (512 bytes) was arbitrary, but chosen because
it is a disk sector size... If you're doing that much AES, on a slower
machine, you'll probably want to use an accelerator...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131021164034.GU56872>