From owner-freebsd-arch@FreeBSD.ORG  Mon Oct 21 19:01:24 2013
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id 4E4B6F94;
 Mon, 21 Oct 2013 19:01:24 +0000 (UTC)
 (envelope-from phk@phk.freebsd.dk)
Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222])
 by mx1.freebsd.org (Postfix) with ESMTP id 117BC2D87;
 Mon, 21 Oct 2013 19:01:23 +0000 (UTC)
Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3])
 by phk.freebsd.dk (Postfix) with ESMTP id 230DD3EB48;
 Mon, 21 Oct 2013 19:01:23 +0000 (UTC)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
 by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r9LJ1Mh1037966;
 Mon, 21 Oct 2013 19:01:22 GMT (envelope-from phk@phk.freebsd.dk)
To: John-Mark Gurney <jmg@funkthat.com>
Subject: Re: always load aesni or load it when cpu supports it
In-reply-to: <20131021185308.GA56872@funkthat.com>
From: "Poul-Henning Kamp" <phk@phk.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>
 <20131021185308.GA56872@funkthat.com>
Content-Type: text/plain; charset=ISO-8859-1
Date: Mon, 21 Oct 2013 19:01:22 +0000
Message-ID: <37965.1382382082@critter.freebsd.dk>
Cc: Andre Oppermann <andre@freebsd.org>, Mark R V Murray <mark@grondar.org>,
 freebsd-arch@freebsd.org
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Oct 2013 19:01:24 -0000

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.