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

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

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

On Tue, 2005-05-03 at 20:29 +1000, Herbert Xu wrote:
> On Tue, May 03, 2005 at 02:31:35PM +0400, Evgeniy Polyakov wrote:
> >
> > Asynchronous processing will not hurt synchronous pathes in any way.
> 
> It will if you force everybody to go through the asynchronous path
> because you're jacking up the latency.

But if it will not be selected - IPsec users will not be affected.

Using asynchronous crypto processing of course has it's own nitpics,
and although it's value was prooven [1] to be unsignificant, it is
still 
there.

Current IPsec processing [even if it is UP only] has very strong model
which
always gets the maximum only from synchronous crypto.

If people select asynchronous IPsec processing - they will use 
_asynchronous_ IPsec processing, and no _synchronous_ pathes will be 
affected.
Using asynchronous IPsec processing is only usefull with asynchronous
crypto layers, so no need to turn it on if none could be used with
hardware.

Btw, current crypto schema by design is SMP unfriendly - there is
only low-level TFM entity, which 
1. must be recreated for several CPUs
2. caller must know about how many CPUs are, which TFM to use and so on.

Asynchronous crypto layers allow to hide it using proper API.

I doubt there will be any benfit for existing IPsec schema from several
CPUs without either some crypto processing rewrite
(either by using per-cpu xfrm states or using several tfms per
transformer),
or without using some asynchronous crypto processing schema...


[1] http://www.openbsd.org/papers/ocf.pdf

-- 
        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 --]