Date: Mon, 21 Oct 2013 19:01:22 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: John-Mark Gurney <jmg@funkthat.com> 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: <37965.1382382082@critter.freebsd.dk> In-Reply-To: <20131021185308.GA56872@funkthat.com> 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> <20131021185308.GA56872@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20131021185308.GA56872@funkthat.com>, John-Mark Gurney writes: >> 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... Yes, "its complicated", and my point is that we should isolate that complication one place, rather than spread it all over the place. Obviously the API must have an open() where the crypto-consumer state their intentions, which algo(s), which mode(s), what sizes etc, to give the central crypto-service useful info for heuristics. The actual trafic-densisty, if that is going to be a factor, should be measured however. Code is notoriously bad at guessing the intention behind its activation. GBDE certainly cannot tell up front if its going to be a busy filesystem or not. Needless to say, that may be also be function of time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37965.1382382082>