From owner-freebsd-arch@FreeBSD.ORG Sun Oct 20 07:00:24 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 83E1C548 for ; Sun, 20 Oct 2013 07:00:24 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 67DAF2941 for ; Sun, 20 Oct 2013 07:00:23 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r9K70Mi6024675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 20 Oct 2013 00:00:23 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r9K70MjL024674 for freebsd-arch@FreeBSD.org; Sun, 20 Oct 2013 00:00:22 -0700 (PDT) (envelope-from jmg) Date: Sun, 20 Oct 2013 00:00:22 -0700 From: John-Mark Gurney To: freebsd-arch@FreeBSD.org Subject: always load aesni or load it when cpu supports it Message-ID: <20131020070022.GP56872@funkthat.com> Mail-Followup-To: freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 20 Oct 2013 00:00:23 -0700 (PDT) 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: Sun, 20 Oct 2013 07:00:24 -0000 So, I'd like to get aesni more widely used. I didn't even realize one of my AMD cpus even supported AES-NI till I decided to look at the caps and realized it did. If we had been loading the AES-NI module, I would have realized it sooner. So, should we now add it to GENERIC? or should we (and by we, I mean I) add code to loader to load it when the cpu supports it? Yes, the aesni module is small, but dynamicly loading it would allow us to continue to keep the kernel small, and this could possibly be used as a framework for other modules too. Comments? Suggestions or ideas? Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sun Oct 20 10:38:27 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 D2827673 for ; Sun, 20 Oct 2013 10:38:27 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99D652140 for ; Sun, 20 Oct 2013 10:38:27 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VXqOs-0001P4-Dh; Sun, 20 Oct 2013 11:38:25 +0100 Subject: Re: always load aesni or load it when cpu supports it Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A39741BD-CA0B-4BE0-A222-AA25E09B586C"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <20131020070022.GP56872@funkthat.com> Date: Sun, 20 Oct 2013 11:38:16 +0100 Message-Id: <423D921D-6CE5-49D9-BCED-AB14EB236800@grondar.org> References: <20131020070022.GP56872@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1510) X-SA-Score: -2.2 Cc: 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: Sun, 20 Oct 2013 10:38:27 -0000 --Apple-Mail=_A39741BD-CA0B-4BE0-A222-AA25E09B586C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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. M -- Mark R V Murray --Apple-Mail=_A39741BD-CA0B-4BE0-A222-AA25E09B586C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUmOynd58vKOKE6LNAQroTAQAmdk85tHD2w9udTD3Ychqn/aNSdIqAGM/ Mi3CFK4XhK4bGytwUMPLjtw9Ekbq/9csD9PjFlpHZtZVcNBxw1Ot0nDb0hQ8SfEd LBJ3+HtLwJ4muZLEN7JaqCZ2S+FZ/425mdOQSM1433Fbr/kWgorE5WaPlXhYdB/r ich9qR08VMw= =PFHK -----END PGP SIGNATURE----- --Apple-Mail=_A39741BD-CA0B-4BE0-A222-AA25E09B586C-- From owner-freebsd-arch@FreeBSD.ORG Sun Oct 20 16:16:36 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 C5ECFB28 for ; Sun, 20 Oct 2013 16:16:36 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A3E0320F8 for ; Sun, 20 Oct 2013 16:16:36 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r9KGGZ3K031615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Oct 2013 09:16:35 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r9KGGYSU031614; Sun, 20 Oct 2013 09:16:34 -0700 (PDT) (envelope-from jmg) Date: Sun, 20 Oct 2013 09:16:34 -0700 From: John-Mark Gurney To: Mark R V Murray Subject: Re: always load aesni or load it when cpu supports it Message-ID: <20131020161634.GQ56872@funkthat.com> Mail-Followup-To: Mark R V Murray , freebsd-arch@FreeBSD.org References: <20131020070022.GP56872@funkthat.com> <423D921D-6CE5-49D9-BCED-AB14EB236800@grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <423D921D-6CE5-49D9-BCED-AB14EB236800@grondar.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 20 Oct 2013 09:16:36 -0700 (PDT) Cc: 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: Sun, 20 Oct 2013 16:16:36 -0000 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... 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? 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... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 07:11:48 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 7AF155F4 for ; Mon, 21 Oct 2013 07:11:48 +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 404932F95 for ; Mon, 21 Oct 2013 07:11:47 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4EF0C3EB6A; Mon, 21 Oct 2013 07:11:41 +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 r9L7BdAi005354; Mon, 21 Oct 2013 07:11:40 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney Subject: Re: always load aesni or load it when cpu supports it In-reply-to: <20131020161634.GQ56872@funkthat.com> From: "Poul-Henning Kamp" References: <20131020070022.GP56872@funkthat.com> <423D921D-6CE5-49D9-BCED-AB14EB236800@grondar.org> <20131020161634.GQ56872@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 21 Oct 2013 07:11:39 +0000 Message-ID: <5353.1382339499@critter.freebsd.dk> 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 07:11:48 -0000 In message <20131020161634.GQ56872@funkthat.com>, John-Mark Gurney writes: >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... The reason GBDE didn't use OpenCrypto was that it was horribly slow compared to direct CPU execution. I couldn't find one single computer where using the available hardware were faster. I spent a lot of time with HiFn chips, and later with the Via chips instruction-based AES, and a rather clear picture emerged for me. "Distant crypto HW", like the HiFn and pretty much anything else on the far side of the L[123] cache, is unsuitable for what I will call "synchronous" crypto, where the CPU needs to do something and then continue with the result. It _can_ work for "asynchronous crypto", where the CPU queues some work and the hw-crypto interrupt handler can schedule it where it needs to go next, typically a device-driver queue. With the overheads I measured, you still need pretty massive amounts of traffic before it pays off, or put another way: As long as you have free CPU-cycles, it will not. I havn't looked at opencrypto recently, but back then it was pretty much a IPSEC facility with a proof-of-concept userland device driver. I tried to add a more generic facility so that it could also be usable for disk-I/O, and when that failed to get results I added a GEOM specific facility, but even that I never managed to get to improve GBDE performance[1], so I never committed it. My suggestion moving forward, is to implement this distinction between "synchronous crypto" and "asynchronous crypto" (or maybe "CPU crypto" vs. "IO crypto" ?) in the architecture, and stop pretending that OpenCrypto will ever cater to both needs. For CPU crypto I would simply do the memcpy() thing: Have a function pointer replaced with CPU-specific code if available. Please notice that this should happen in userland too, and should be standardized across operating systems, so ports can use it to forego their private C&P copies of common crypto algorithms. (see also: http://queue.acm.org/detail.cfm?id=1944489) Also notice that we will see more of this kind of "CISC-Creep" in the future: Intel and AMD needs to find ways to spend transistors to claim speedups, so we will get more and more weird instructions for speeding up tight loops. Make whatever you do able to also handle when sprintf(3) becomes an instruction. Poul-Henning [1] GBDE is a bit of a trouble-maker because it changes keys all the time, but unless you can dedicate a crypto-instance to you don't have to do key-setup, this makes no difference in practice. OpenCrypto did not have support for "reserving" crypto instances this way last I looked. -- 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. 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 From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 16:40:36 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1486812D; Mon, 21 Oct 2013 16:40:36 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8123242B; Mon, 21 Oct 2013 16:40:35 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r9LGeZGh052549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 09:40:35 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r9LGeYss052548; Mon, 21 Oct 2013 09:40:34 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Oct 2013 09:40:34 -0700 From: John-Mark Gurney To: Andre Oppermann Subject: Re: always load aesni or load it when cpu supports it Message-ID: <20131021164034.GU56872@funkthat.com> Mail-Followup-To: Andre Oppermann , Mark R V Murray , freebsd-arch@freebsd.org References: <20131020070022.GP56872@funkthat.com> <423D921D-6CE5-49D9-BCED-AB14EB236800@grondar.org> <20131020161634.GQ56872@funkthat.com> <5264F074.4010607@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5264F074.4010607@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 21 Oct 2013 09:40:35 -0700 (PDT) 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 16:40:36 -0000 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 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." From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 18:22:11 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2205ACE6; Mon, 21 Oct 2013 18:22:11 +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 D9DE92B2F; Mon, 21 Oct 2013 18:22:10 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8B75F3EB6C; Mon, 21 Oct 2013 18:22:09 +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 r9LIM8CX037694; Mon, 21 Oct 2013 18:22:08 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney Subject: Re: always load aesni or load it when cpu supports it In-reply-to: <20131021164034.GU56872@funkthat.com> From: "Poul-Henning Kamp" References: <20131020070022.GP56872@funkthat.com> <423D921D-6CE5-49D9-BCED-AB14EB236800@grondar.org> <20131020161634.GQ56872@funkthat.com> <5264F074.4010607@freebsd.org> <20131021164034.GU56872@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 21 Oct 2013 18:22:08 +0000 Message-ID: <37693.1382379728@critter.freebsd.dk> Cc: Andre Oppermann , 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 18:22:11 -0000 In message <20131021164034.GU56872@funkthat.com>, John-Mark Gurney writes: >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... I'd say it is both arbitrary and pointless. Logical "disk-sectors" under both GBDE and GELI can be any size (think RAID-5 stripe) and consumer harddisks have 4K sectors these days. Why do you fee a limit is necessary ? -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 18:28:35 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 8678E3D3; Mon, 21 Oct 2013 18:28:35 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 623CE2B82; Mon, 21 Oct 2013 18:28:35 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r9LISYIR054070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 11:28:34 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r9LISY3D054069; Mon, 21 Oct 2013 11:28:34 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Oct 2013 11:28:34 -0700 From: John-Mark Gurney To: Poul-Henning Kamp Subject: Re: always load aesni or load it when cpu supports it Message-ID: <20131021182834.GX56872@funkthat.com> Mail-Followup-To: Poul-Henning Kamp , Andre Oppermann , Mark R V Murray , freebsd-arch@freebsd.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37693.1382379728@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 21 Oct 2013 11:28:35 -0700 (PDT) Cc: Andre Oppermann , 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 18:28:35 -0000 Poul-Henning Kamp wrote this message on Mon, Oct 21, 2013 at 18:22 +0000: > In message <20131021164034.GU56872@funkthat.com>, John-Mark Gurney writes: > > >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... > > I'd say it is both arbitrary and pointless. > > Logical "disk-sectors" under both GBDE and GELI can be any size > (think RAID-5 stripe) and consumer harddisks have 4K sectors these days. > > Why do you fee a limit is necessary ? If you're on a slow system (embeded x86 or arm) that has an AES accelerator, you really want to be using your accelerator than wasting your cpu cycles on large blockes of AES... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 18:32:15 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 21D3F4CE; Mon, 21 Oct 2013 18:32:15 +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 DA26B2BD6; Mon, 21 Oct 2013 18:32:14 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 8F74F3EB4A; Mon, 21 Oct 2013 18:32:13 +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 r9LIWDRx037749; Mon, 21 Oct 2013 18:32:13 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney Subject: Re: always load aesni or load it when cpu supports it In-reply-to: <20131021182834.GX56872@funkthat.com> From: "Poul-Henning Kamp" 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> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 21 Oct 2013 18:32:13 +0000 Message-ID: <37748.1382380333@critter.freebsd.dk> Cc: Andre Oppermann , 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 18:32:15 -0000 In message <20131021182834.GX56872@funkthat.com>, John-Mark Gurney writes: >If you're on a slow system (embeded x86 or arm) that has an AES >accelerator, you really want to be using your accelerator than wasting >your cpu cycles on large blockes of AES... First, as I said in my previous email: I have still to see "distant" crypto accelerator do any good if you have idle CPU, even on a soekris 4801. If you have a real-life benchmark showing that, I'd like to see it. Second, if you want a limit, at the very least it should be MAXPHYS. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 18:36:59 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 C7E495AC; Mon, 21 Oct 2013 18:36:59 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88D6F2BF5; Mon, 21 Oct 2013 18:36:59 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r9LIawvO054209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 11:36:59 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r9LIawXe054208; Mon, 21 Oct 2013 11:36:58 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Oct 2013 11:36:58 -0700 From: John-Mark Gurney To: Poul-Henning Kamp Subject: Re: always load aesni or load it when cpu supports it Message-ID: <20131021183658.GY56872@funkthat.com> Mail-Followup-To: Poul-Henning Kamp , Andre Oppermann , Mark R V Murray , freebsd-arch@freebsd.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37748.1382380333@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 21 Oct 2013 11:36:59 -0700 (PDT) Cc: Andre Oppermann , 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 18:36:59 -0000 Poul-Henning Kamp wrote this message on Mon, Oct 21, 2013 at 18:32 +0000: > In message <20131021182834.GX56872@funkthat.com>, John-Mark Gurney writes: > > >If you're on a slow system (embeded x86 or arm) that has an AES > >accelerator, you really want to be using your accelerator than wasting > >your cpu cycles on large blockes of AES... > > First, as I said in my previous email: I have still to see "distant" > crypto accelerator do any good if you have idle CPU, even on a soekris 4801. ^^^^^^^^^ If you don't have idle cpu? Also, what about power consumption? > If you have a real-life benchmark showing that, I'd like to see it. > > Second, if you want a limit, at the very least it should be MAXPHYS. 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... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 18:42:38 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB3D4883; Mon, 21 Oct 2013 18:42:38 +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 6BFB92C74; Mon, 21 Oct 2013 18:42:38 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 16E183EB51; Mon, 21 Oct 2013 18:42:37 +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 r9LIgask037804; Mon, 21 Oct 2013 18:42:36 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney Subject: Re: always load aesni or load it when cpu supports it In-reply-to: <20131021183658.GY56872@funkthat.com> From: "Poul-Henning Kamp" 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> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 21 Oct 2013 18:42:36 +0000 Message-ID: <37803.1382380956@critter.freebsd.dk> Cc: Andre Oppermann , 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 18:42:38 -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...) Those APIs should do whatever is fastest, for the request it gets. We do *not* want to pollute all crypto-using code with heuristics to guess which API to call for which request and when. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 18:43:11 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 90156A04; Mon, 21 Oct 2013 18:43:11 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D3CB2C7B; Mon, 21 Oct 2013 18:43:11 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r9LIhA5E054311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 11:43:10 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r9LIhADa054310; Mon, 21 Oct 2013 11:43:10 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Oct 2013 11:43:10 -0700 From: John-Mark Gurney To: Poul-Henning Kamp Subject: Re: always load aesni or load it when cpu supports it Message-ID: <20131021184310.GZ56872@funkthat.com> Mail-Followup-To: Poul-Henning Kamp , Andre Oppermann , Mark R V Murray , freebsd-arch@freebsd.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37748.1382380333@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 21 Oct 2013 11:43:11 -0700 (PDT) Cc: Andre Oppermann , 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 18:43:11 -0000 Poul-Henning Kamp wrote this message on Mon, Oct 21, 2013 at 18:32 +0000: > In message <20131021182834.GX56872@funkthat.com>, John-Mark Gurney writes: > > >If you're on a slow system (embeded x86 or arm) that has an AES > >accelerator, you really want to be using your accelerator than wasting > >your cpu cycles on large blockes of AES... > > First, as I said in my previous email: I have still to see "distant" > crypto accelerator do any good if you have idle CPU, even on a soekris 4801. Also depends upon the crypto mode you are using... If you're using CBC encrypt, then you'd need a very fancy accelerator to out perform a CPU, but in other modes like XTS or CTR, an accelerator can/will out perform the CPU... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 18:45:03 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 B6DAFAD2; Mon, 21 Oct 2013 18:45:03 +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 7979F2C95; Mon, 21 Oct 2013 18:45:03 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B31DE3EB5F; Mon, 21 Oct 2013 18:45:02 +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 r9LIj2eC037851; Mon, 21 Oct 2013 18:45:02 GMT (envelope-from phk@phk.freebsd.dk) To: John-Mark Gurney Subject: Re: always load aesni or load it when cpu supports it In-reply-to: <20131021184310.GZ56872@funkthat.com> From: "Poul-Henning Kamp" 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> <20131021184310.GZ56872@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 21 Oct 2013 18:45:02 +0000 Message-ID: <37850.1382381102@critter.freebsd.dk> Cc: Andre Oppermann , 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 18:45:03 -0000 In message <20131021184310.GZ56872@funkthat.com>, John-Mark Gurney writes: >Poul-Henning Kamp wrote this message on Mon, Oct 21, 2013 at 18:32 +0000: >Also depends upon the crypto mode you are using... If you're using >CBC encrypt, then you'd need a very fancy accelerator to out perform >a CPU, but in other modes like XTS or CTR, an accelerator can/will out >perform the CPU... Only for very large requests that can amortize the considerable setup overhead. Either way, we do *not* want the heuristics to guess this spread out over every and all modules which need crypto services. -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 18:53:09 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 CB701E44; Mon, 21 Oct 2013 18:53:09 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A176E2D17; Mon, 21 Oct 2013 18:53:09 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r9LIr8F4054480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 11:53:08 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r9LIr8oY054479; Mon, 21 Oct 2013 11:53:08 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Oct 2013 11:53:08 -0700 From: John-Mark Gurney To: Poul-Henning Kamp Subject: Re: always load aesni or load it when cpu supports it Message-ID: <20131021185308.GA56872@funkthat.com> Mail-Followup-To: Poul-Henning Kamp , Andre Oppermann , Mark R V Murray , freebsd-arch@freebsd.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37803.1382380956@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 21 Oct 2013 11:53:09 -0700 (PDT) Cc: Andre Oppermann , 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 18:53:10 -0000 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." From owner-freebsd-arch@FreeBSD.ORG Mon Oct 21 19:01:24 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 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 Subject: Re: always load aesni or load it when cpu supports it In-reply-to: <20131021185308.GA56872@funkthat.com> From: "Poul-Henning Kamp" 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 , 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 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.