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

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

On Tue, 2005-05-03 at 20:14 +1000, Herbert Xu wrote:
> On Tue, May 03, 2005 at 02:18:22PM +0400, Evgeniy Polyakov wrote:
> > 
> > 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.
> 
> Well if there were no better options then we'll have to do that.
> 
> However, I believe that with the right crypto API we should be
> able to have async crypto support without sacrificing synchronous
> performance.

Asynchronous processing will not hurt synchronous pathes in any way.

But in some places we can use async api easily - like block devices
encryption, but for others - like IPsec, there is no ability
to split packet processing and thus even use async api.
How carefully asynchronous API would be created current IPsec code
just can not use it.

> > It looks like several CPUs can not be used for synchronous crypto
> > processing in current IPsec implementation. Using asynchronous
> 
> That's just an implementation quirk.  I will be addressing that
> soon as part of the xfrm locking clean-up.

That is not enough, as far as I can see, since only one tfm is used
for one transformer state.
Locking changes will allow parallel processing of AH and ESP for
example,
but not two packets from the same flow.

> Cheers,
-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]