From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 21 13:27:58 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 280081065673; Sat, 21 Jun 2008 13:27:58 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [213.186.42.107]) by mx1.freebsd.org (Postfix) with ESMTP id AF2698FC17; Sat, 21 Jun 2008 13:27:57 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (15.10.87-79.rev.gaoland.net [79.87.10.15]) by smtp.lamaiziere.net (Postfix) with ESMTP id 1C73411805AD; Sat, 21 Jun 2008 15:27:56 +0200 (CEST) Received: from baby-jane-lamaiziere-net.local (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id A4B634F79C4; Sat, 21 Jun 2008 15:27:54 +0200 (CEST) Date: Sat, 21 Jun 2008 15:27:51 +0200 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: Pawel Jakub Dawidek Message-ID: <20080621152751.4aebc9e9@baby-jane-lamaiziere-net.local> In-Reply-To: <20080607041855.GA3462@garage.freebsd.pl> References: <20080606234135.46144207@baby-jane-lamaiziere-net.local> <20080607041855.GA3462@garage.freebsd.pl> Organization: /dave/nulle X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.8; i386-apple-darwin9.2.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: AMD Geode LX crypto accelerator (glxsb) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2008 13:27:58 -0000 Le Sat, 7 Jun 2008 06:18:55 +0200, Pawel Jakub Dawidek a écrit : Hello, > On Fri, Jun 06, 2008 at 11:41:35PM +0200, Patrick Lamaizi?re wrote: > > Dears, > > > > I'm trying to port the glxsb driver from OpenBSD to FreeBSD 7-STABLE > > (via the NetBSD port). > > Cool. > > > " The glxsb driver supports the security block of the Geode LX > > series processors. The Geode LX is a member of the AMD Geode family > > of integrated x86 system chips. > > > > Driven by periodic checks for available data from the generator, > > glxsb supplies entropy to the random(4) driver for common usage. > > > > glxsb also supports acceleration of AES-128-CBC operations for > > crypto(4)." [cut] > > - The driver does a busy wait to check the completion of the > > encryption. I think it would be beter to use the interrupt. I will > > look later. > > I remember looking at that code sometime ago and that bit is really > lame, so lame that I think they would do it in a different way if that > was possible. Maybe it's worth contacting OpenBSD/NetBSD and ask? > There might be a good reason for that. I've made some tests that use the interrupt for completion. It is far slower than the "busy wait" in "real time". Tests to encrypt a file (361Mbytes) with openssl /usr/bin/time -h openssl enc -e -aes-128-cbc -in file -out /dev/null -k abcdefghijk -nosalt - Without the hardware : 1m11.57s real 1m7.69s user 3.34s sys - With cryptodev and interrupt 1m27.08s real 1.58s user 6.85s sys - With cryptodev and a busy wait in crypto_process() (the actual version of the driver) 18.41s real 1.51s user 16.75s sys - With cryptodev and a busy wait, but instead of blocking in crypto_process() (i think it's really bad), I use a taskqueue(9) to process the encryption. 21.11s real 1.57s user 6.41s sys So with a taskqueue, it seems less agressive for the kernel but it takes a litle more amount of time to complete. Anyway i can't uses a busy wait in crypto_process(), the man of crypto(9) says: "The process() routine is invoked with a request to perform crypto processing. This routine must not block, but should queue the request and return immediately." I would like your comments about the use of the task queue. I am not sure if i used the Good Way To Do(TM). - I use a private taskqueue with priority PI_NET. Is it Ok for the priority ? Shall I use a predefined system taskqueue instead ? - Only one task can be enqueued at a time, so i have to block the Open crypto framework, i use a counter (int) protected by a mutex. If a task is being processing, crypto_process() return ERESTART to block the crypto engine. static int crypto_process() { ... mtx_lock(&sc->sc_crypto_mtx); if (sc->sc_busy != 0) { mtx_unlock(&sc->sc_crypto_mtx); return (ERESTART); } sc->sc_busy++; mtx_unlock(&sc->sc_crypto_mtx); taskqueue_enqueue(sc->sc_tq, &sc->sc_crypto_task); return(0); } /* the task */ void crypto_task(void *arg, int pending) { [perform encryption] mtx_lock(&sc->sc_crypto_mtx); sc->sc_busy--; mtx_unlock(&sc->sc_crypto_mtx); /* shall i check that we are blocked ?*/ crypto_unblock(sc->sc_cid, CRYPTO_SYMQ); crypto_done(crp); } Does it look good ? > Looks good:) I can do a final review and commit once you are done and > if I'll be able to start my Soekris and test it. Thank you. I have to cleanup the code and check the taskqueue stuff i added. After I will ask on the soekris mailing list if someone can help to test, I don't have any feed back for the moment. I'm asking what stuff i shall provide for a review and commit ? A patch againt CURRENT ? Regards.