On Tue, Aug 23, 2005 at 01:02:09PM -0500, Kim Phillips ([EMAIL PROTECTED]) 
wrote:
> On Tue, 23 Aug 2005 20:12:12 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, Aug 23, 2005 at 06:40:42PM +0300, Ronen Shitrit ([EMAIL PROTECTED]) 
> > wrote:
> > > Hi
> > > 
> > > The device I'm planning to use can support synchronous encryption, but
> > > Isn't any device can do it, by polling the device till it complete?
> > > Won't it be a waste of time, waiting for the HW accelerator to complete
> > > processing,
> > > While other tasks can use the CPU?
> > 
> > Sure.
> > I mean VIA/Freescale like processing - it does not support asynchronous
> > processing, but instead doing crypto operations like original CPU
> > instructions.
> > 
> fyi, Freescale's SEC crypto engine is asynchronous to the core, i.e. the core 
> CPU is free during crypto processing.  
> 
> Currently, I see no point in porting the existing tfm crypto api to a 
> freescale device, except perhaps in preparation/anticipation for Herbert's 
> async mods.  If you're porting to a Freescale device for use with IPSec, 
> you'd want an API to provide single-pass, e.g. encrypt-and-hash operations, 
> which the Freescale device supports natively.  I believe OCF supports this.

Yes, you are right, I thought ColdFire's SEC is synchronous
in respect to input dataflow.

So, currently only VIA ACE xcrypt is fully synchronous and 
can be (and it is) supported under existing TFM stack.

I agree theres is no need to port existing asynchronous crypto drivers
like freescale, HIFN, IXP and others to TFM stack.

> Kim

-- 
        Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to