Re: Asynchronous crypto layer.

From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: hadi@cyberus.ca
Cc: Michal Ludvig <mludvig@suse.cz>,
	netdev@oss.sgi.com, cryptoapi@lists.logix.cz,
	Eugene Surovegin <ebs@ebshome.net>
Subject: Re: Asynchronous crypto layer.
Date: Mon, 01 Nov 2004 09:01:44 +0300	[thread overview]
Message-ID: <1099288904.5070.75.camel@uganda> (raw)
In-Reply-To: <1099235030.1038.192.camel@jzny.localdomain>

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

On Sun, 2004-10-31 at 18:03, jamal wrote:
> On Sun, 2004-10-31 at 05:46, Michal Ludvig wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> 
> > Yes, I have *some* numbers, but consider that they are for quite
> > eligible setup - encrypting ~1.5k IPsec packets. I should retry with a
> > much smaller MTU to see the difference...
> > 
> 
> You should try with different packet sizes for different hardware, or
> s/ware drivers with and without async; with and without batching.
> packet sizes 64,256,512,1024,1500 bytes. batch sizes, 1,2,4,8,16,..
> 
> > I think it won't be the programmer but the system administrator who will
> > have to correctly set priorities and constraints for different
> > hardware/software engines for the particular system. 
> 
> Why is the admin involved in such decision making?
> 
> > With a slow CPU it
> > may be worth to offload even small blocks to hardware, with a fast one
> > it may be worth to set HW and SW as equal, etc.
> > 
> 
> I think the system should discover all this at runtime.
> If the driver says its busy, you dont give it more work.
> Clearly giving it more data is beneficial; hence before it gets busy
> you give it enough to overcome the setup cost.
> You should have qos (start with simple strict priority); and the
> preference could be given to large packets etc as long as you dont
> introduce reordering.

Crypto session priority already exists - sessions are placed into 
the queues in order of it's priority.
It is supposed that crypto device driver will get them in this order
too.

> Come to think of it, this would be really easily doable if the crypto
> device appeared to the system as a netdevice.

:) First of all it would be good to stabilize what we already have.

> cheers,
> jamal
> 
> _______________________________________________
> 
> Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi
> List archive: http://lists.logix.cz/pipermail/cryptoapi
-- 
	Evgeniy Polyakov

Crash is better than data corruption. -- Art Grabowski

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]