From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 09:14:46 2013 Return-Path: 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 3F926804 for ; Mon, 21 Oct 2013 09:14:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88DEB27A4 for ; Mon, 21 Oct 2013 09:14:45 +0000 (UTC) Received: (qmail 41427 invoked from network); 21 Oct 2013 09:46:41 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2013 09:46:41 -0000 Message-ID: <5264F074.4010607@freebsd.org> Date: Mon, 21 Oct 2013 11:14:28 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: jmg@funkthat.com Subject: Re: always load aesni or load it when cpu supports it References: <20131020070022.GP56872@funkthat.com> <423D921D-6CE5-49D9-BCED-AB14EB236800@grondar.org> <20131020161634.GQ56872@funkthat.com> In-Reply-To: <20131020161634.GQ56872@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark R V Murray , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 09:14:46 -0000 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 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