From: Eugene Surovegin <ebs@ebshome.net>
To: remy.gauguey@mindspeed.com
Cc: linux-crypto@nl.linux.org, linux-kernel@vger.kernel.org
Subject: Re: Linux 2.6 crypto API and HW accelerators
Date: Tue, 4 May 2004 09:17:26 -0700 [thread overview]
Message-ID: <20040504161726.GA25795@gate.ebshome.net> (raw)
In-Reply-To: <OF4ED7CD00.900586C8-ONC1256E8A.00491716-C1256E8A.004B08FD@nice.mindspeed.com>
On Tue, May 04, 2004 at 03:39:35PM +0200, remy.gauguey@mindspeed.com wrote:
> I'm currently working on a ARM920T based network processor with arm-linux
> kernel 2.6.5.
> This device has a crypto hardware accelerator dedicated to IPsec.
> In ESP mode the device can do authentication (SHA-1, MD5) as well as
> encryption (AES, TDES in CBC or ECB mode) in one pass.
> Unfortunately current Linux 2.6 crypto API doesn't support this kind of
> hardware accelerator. Current crypto module relies on crypto algorithms
> which are called for a single operation and for each block.
>
> Then, I would like to know if other people are working on the hardware
> crypto support in kernel 2.6.x.
> If so, what would be the plan ? crypto api improvement or new IPsec
> specific hardware support ?
>
I wrote a driver recently for Hifn 7955 crypto processor for use in low-end PPC
box (PPC 440, 500Mhz).
I added simple extension for current Crypto API, basically a pass-through path.
Patches can be found and http://kernel.ebshome.net (patches are of alpha
quality, and were never tested on x86 :)
In short, my experience showed that without significant changes in current
implementation, e.g. adding async crypto, adding hardware crypto is worth only
for relatively slow CPUs, e.g. less than 1Ghz, and even with slow processor
overhead can be so big, that short packets are better processed by software
path.
As a side note, in addition to the limitation you noticed (sw crypto is called
for one block), there are another one, currently Linux IPSec implementation
always calls Crypto layer holding BH lock, so hw crypto driver have to busy wait
even when called from process context. Maybe this can be easily changed.
Feel free to contact me privately if you need more information :)
Eugene
next prev parent reply other threads:[~2004-05-04 16:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-04 13:39 remy.gauguey
2004-05-04 16:17 ` Eugene Surovegin [this message]
2004-05-04 19:53 ` James Morris
2004-05-04 19:40 ` James Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040504161726.GA25795@gate.ebshome.net \
--to=ebs@ebshome.net \
--cc=linux-crypto@nl.linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=remy.gauguey@mindspeed.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®