Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Octavian Purdila <opurdila@ixiacom.com>
To: Dimitrios Siganos <dimitris@siganos.org>
Cc: linux-crypto@vger.kernel.org, Alex Badea <abadea@ixiacom.com>,
	ddogaru@ixiacom.com
Subject: Re: ESP hardware acceleration
Date: Tue, 15 Sep 2009 17:54:15 +0300	[thread overview]
Message-ID: <200909151754.15716.opurdila@ixiacom.com> (raw)
In-Reply-To: <4AAF945F.8060501@siganos.org>

On Tuesday 15 September 2009 16:19:27 you wrote:
> Hi,
> 
> We are using linux-2.6.28 and we would like to hardware accelerate the
> NETKEY IPsec traffic. We are using strongswan for the upper layers.
> 
> I understand that strongswan uses the Linux/NETKEY IPsec implementation,
> which in turn, uses the Linux Scatterlist Crypto API for all its
> cryptographic work. To hardware accelerate IPsec, I need to write a
> "Linux Scatterlist Crypto API" driver for my hardware accelerator and
> register it with the linux kernel.
> 
> What I would like to know is:
> 1) does the xfrm/ESP implementation support asynchronous/parallel packet
> operation?
> 2) If yes, does it support it in both directions (tx/rx)?
> 
> Our hardware supports a queue packets for processing and we would like
> to utilise that, to keep the hardware as busy as possible i.e. we would
> like to be able to send multiple packets to the hardware engine for
> encryption/hashing and then receive multiple acknowledgements that the
> packets are ready.
> 

Hi Dimitrios,

AFAK, the crypto interface is asynchronous but the hashing interface (as used 
in IPSec) is synchronous.

There are two patches I've recently seen on the list, one for converting to 
async hashing and one for parallel crypto/ipsec which will probably get in 
2.6.32.

However, I think that the best results for hw accel will be obtained if you 
accelerate the AEAD interface.

Speaking of hw accel, we are also playing with it and we got moderately good 
results. We are now running into two major software bottlenecks: memcpy 
(because of the copy required by TCP traffic) and CRC computation.

To solve the first issue we were thinking of extending the ESP implementation 
to create two scatter-gather lists / skbs, one which will be used as the 
source and once which will be used as the destination. This will allow to 
offload the memcpy operation to hardware.

We will soon start working on this - after a bit of stabilization we need to 
do and we will start pestering you crypto wizards with questions /  patches, 
but in the meanwhile, if you have any advice on this topic we will greatly 
appreciate it :)

Thanks!
tavi

  reply	other threads:[~2009-09-15 14:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-15 13:19 ESP hardware acceleration Dimitrios Siganos
2009-09-15 14:54 ` Octavian Purdila [this message]
2009-09-15 17:12   ` Herbert Xu
2009-09-15 17:57     ` Octavian Purdila
2009-09-15 17:09 ` Herbert Xu

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=200909151754.15716.opurdila@ixiacom.com \
    --to=opurdila@ixiacom.com \
    --cc=abadea@ixiacom.com \
    --cc=ddogaru@ixiacom.com \
    --cc=dimitris@siganos.org \
    --cc=linux-crypto@vger.kernel.org \
    /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