netdev
[Top] [All Lists]

Re: [patch/RFC]: Asynchronous IPsec processing.

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [patch/RFC]: Asynchronous IPsec processing.
From: Evgeniy Polyakov <johnpol@xxxxxxxxxxx>
Date: Tue, 03 May 2005 14:18:22 +0400
Cc: netdev@xxxxxxxxxxx, Patrick McHardy <kaber@xxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, Jamal Hadi Salim <hadi@xxxxxxxxxx>
In-reply-to: <20050503095312.GA29788@gondor.apana.org.au>
Organization: MIPT
References: <20050429144103.A23268@2ka.mipt.ru> <20050503095312.GA29788@gondor.apana.org.au>
Reply-to: johnpol@xxxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Tue, 2005-05-03 at 19:53 +1000, Herbert Xu wrote:
> On Fri, Apr 29, 2005 at 02:41:03PM +0400, Evgeniy Polyakov wrote:
> > 
> > I've created POC code to perform asynchronous IPsec [ESP]
> > processing. Please comment about bugs in the following patch.
> > It of course very dirty - but it is only begining, 
> > I just want to know if approach is right.
> > Patch was tested with several ssh session and some 
> > traffic like find / and tcpdump over them.
> 
> IMHO we should ensure that the async code path does not adversely
> impact synchronous crypto performance.  Most users will be using
> synchronous crypto primitives.  Synchronous crypto is also the best
> way to utilise VIA Padlock which is arguably the best hardware crypto
> solution that's available today.

It can be compile option - those people who wants asynchronous crypto
processing and has appropriate hardware will benefit from that even
if theirs general purpose CPU is VIA with PadLock ACE.

It looks like several CPUs can not be used for synchronous crypto
processing in current IPsec implementation. Using asynchronous
mode there might be significant performance win.

> Cheers,
-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachment: signature.asc
Description: This is a digitally signed message part

<Prev in Thread] Current Thread [Next in Thread>