On 29 Oct 2004 08:42:18 -0400
jamal <hadi@xxxxxxxxxx> wrote:
> On Fri, 2004-10-29 at 02:22, Evgeniy Polyakov wrote:
> > I'm pleased to announce asynchronous crypto layer for Linux kernel 2.6.
> > It support following features:
> > - multiple asynchronous crypto device queues
> > - crypto session routing
> > - crypto session binding
> > - modular load balancing
> > - crypto session batching genetically implemented by design
> > - crypto session priority
> > - different kinds of crypto operation(RNG, asymmetrical crypto, HMAC and
> > any other)
> Very nice.
> I am very curious if you see perfomance improvements over old scheme
> in the case of a single crypto chip in a fast CPU.
> It has been shown in the past that with a xeon in the range of 2Ghz the
> context setup and the big lock (and lack of async) implied that
> performance enhancement using a crypto chip was negligible.
> IIRC, the only time it started showing anything useful was when a
> compute intensive alg like 3DES was chewing packets >= 1000 bytes.
> My suspicion is you will show it is better to use a crypto chip with
> async;-> In the minimal you should show some improvement.
If we have a hardware accelerator chip, than we _already_ have improvements
with even the worst async crypto layer, since software and hardware
will work in parrallel.
I agree that multigigahertz box will beat my HIFN card,
but I doubt it can beat 1gghz VIA.
And what about random numbers, async crypto, TPM?
They all requires some kind of generalization.
Only failure makes us experts. -- Theo de Raadt