Date: Sat, 21 Jun 2008 15:27:51 +0200 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= <patfbsd@davenulle.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: AMD Geode LX crypto accelerator (glxsb) 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Le Sat, 7 Jun 2008 06:18:55 +0200,
Pawel Jakub Dawidek <pjd@FreeBSD.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080621152751.4aebc9e9>