AMD Geode LX crypto accelerator (glxsb)

Patrick Lamaizière patfbsd at
Sat Jun 21 13:27:58 UTC 2008

Le Sat, 7 Jun 2008 06:18:55 +0200,
Pawel Jakub Dawidek <pjd at> a écrit :


> 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)."


> > - 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() {
 if (sc->sc_busy != 0) {
	return (ERESTART);

 taskqueue_enqueue(sc->sc_tq, &sc->sc_crypto_task);

/* the task */
void crypto_task(void *arg, int pending)
  [perform encryption]


/* shall i check that we are blocked ?*/
   crypto_unblock(sc->sc_cid, CRYPTO_SYMQ);

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

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 ?


More information about the freebsd-hackers mailing list