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:

quoted

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.

quoted

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