netdev
[Top] [All Lists]

Re: Asynchronous crypto layer.

To: hadi@xxxxxxxxxx
Subject: Re: Asynchronous crypto layer.
From: Evgeniy Polyakov <johnpol@xxxxxxxxxxx>
Date: Fri, 29 Oct 2004 19:37:20 +0400
Cc: netdev@xxxxxxxxxxx, cryptoapi@xxxxxxxxxxxxxx
In-reply-to: <1099062483.1023.21.camel@xxxxxxxxxxxxxxxx>
Organization: MIPT
References: <1099030958.4944.148.camel@uganda> <1099053738.1024.104.camel@xxxxxxxxxxxxxxxx> <20041029180652.113f0f6e@xxxxxxxxxxxxxxxxxxxx> <1099062483.1023.21.camel@xxxxxxxxxxxxxxxx>
Reply-to: johnpol@xxxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On 29 Oct 2004 11:08:03 -0400
jamal <hadi@xxxxxxxxxx> wrote:

> On Fri, 2004-10-29 at 10:06, Evgeniy Polyakov wrote:
> 
> 
> > 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.
> 
> Thats what i am hoping - and theory points to it. Numbers, numbers
> please ;->

Michal already have numbers with his patches, that(I studied crypto-dev patch) 
implements acrypto not from the scratch but as a addendum for syncronous crypto
layer, so this approach already has nitpicks.

> > I agree that multigigahertz box will beat my HIFN card, 
> > but I doubt it can beat 1gghz VIA.
> 
> The VIA is an interesting one; but it would still be interesting to see 
> comparisons.
> Actually I should say a good comparison will be with a dual opteron
> >= 2Ghz which i have no doubt will smoke a xeon - all in s/ware.

He-he, dual Opteron? It costs as 5 Via boards :)

ok, I will follow this plan:
I will create simple block device like cryptoloop, it will be _really_ simple
without any kind of portability and/or stability (I hope it will be
one day, at least it took so for 2.4) and I will measure async vs sync.
Then Michal can measure it's fcrypt driver also.

> > And what about random numbers, async crypto, TPM?
> > They all requires some kind of generalization.
> > 
> 
> Similar deferal approach should do it.
> If you are brave, you should probably experiment as well with
> non-crypto stuff to defer things like gettimeofday computes.
> (i.e ask the hardware for time, defer response and then call netif_rx
> with a tag saying time has been computed).

gettimeofday is to fast to use in async schema - in such times
context switching already plays big role.

> cheers,
> jamal
> 
> 


        Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

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