netdev
[Top] [All Lists]

Re: Asynchronous crypto layer.

To: hadi@xxxxxxxxxx
Subject: Re: Asynchronous crypto layer.
From: Evgeniy Polyakov <johnpol@xxxxxxxxxxx>
Date: Mon, 01 Nov 2004 09:01:44 +0300
Cc: Michal Ludvig <mludvig@xxxxxxx>, netdev@xxxxxxxxxxx, cryptoapi@xxxxxxxxxxxxxx, Eugene Surovegin <ebs@xxxxxxxxxxx>
In-reply-to: <1099235030.1038.192.camel@jzny.localdomain>
Organization: MIPT
References: <1099030958.4944.148.camel@uganda> <1099053738.1024.104.camel@jzny.localdomain> <20041029180652.113f0f6e@zanzibar.2ka.mipt.ru> <20041030203550.GB6256@gate.ebshome.net> <20041031010415.4c798a04@zanzibar.2ka.mipt.ru> <20041030205630.GD6256@gate.ebshome.net> <20041031012423.74b98698@zanzibar.2ka.mipt.ru> <1099179687.1041.117.camel@jzny.localdomain> <20041031121308.648e98f9@zanzibar.2ka.mipt.ru> <4184C286.3000400@suse.cz> <1099235030.1038.192.camel@jzny.localdomain>
Reply-to: johnpol@xxxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
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: signature.asc
Description: This is a digitally signed message part

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