Date: Mon, 21 Oct 2013 11:53:08 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Andre Oppermann <andre@freebsd.org>, 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: <20131021185308.GA56872@funkthat.com> In-Reply-To: <37803.1382380956@critter.freebsd.dk> References: <20131020070022.GP56872@funkthat.com> <423D921D-6CE5-49D9-BCED-AB14EB236800@grondar.org> <20131020161634.GQ56872@funkthat.com> <5264F074.4010607@freebsd.org> <20131021164034.GU56872@funkthat.com> <37693.1382379728@critter.freebsd.dk> <20131021182834.GX56872@funkthat.com> <37748.1382380333@critter.freebsd.dk> <20131021183658.GY56872@funkthat.com> <37803.1382380956@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote this message on Mon, Oct 21, 2013 at 18:42 +0000:
> In message <20131021183658.GY56872@funkthat.com>, John-Mark Gurney writes:
> >Poul-Henning Kamp wrote this message on Mon, Oct 21, 2013 at 18:32 +0000:
>
> >Clearly you didn't completely read my first email, so you're proposing
> >that we ALWAYS use software AES and never use AES-NI? At least in the
> >context of my email, that is what the above statement says...
>
> No, what I'm saying is that we should offer two APIs: One synchronous
> and one for IPSEC and any other async usage (personally I can't think
> of any but...)
Ahh, that is very different than disagreeing w/ my size split between
the two API's... Thanks for stating your disagreement w/ my original
proposal...
> Those APIs should do whatever is fastest, for the request it gets.
Except that it isn't that simple... AES-NI isn't free in the kernel
because we have to dump FPU context and do other work that means for
single block AES, it's probably faster to do pure software than doing
the FPU work necessary to use AES-NI...
Also, my proposal was how to get us closer to the end goal w/o breaking
the entire kernel...
> We do *not* want to pollute all crypto-using code with heuristics to
> guess which API to call for which request and when.
Except that the using the API knows what they are likely to do, is it
just one block here and there, or tons of large blocks? you're the one
that wants a "simple synchronous" API, except that we can't have a
performant implementation and a simple synchronous API... We get the
performance by moving the expensive parts outside the inner loop...
which can only be achieved by a more complicated API...
--
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?20131021185308.GA56872>