netdev
[Top] [All Lists]

Re: Asynchronous crypto layer.

To: Michal Ludvig <mludvig@xxxxxxx>
Subject: Re: Asynchronous crypto layer.
From: jamal <hadi@xxxxxxxxxx>
Date: 31 Oct 2004 10:03:50 -0500
Cc: johnpol@xxxxxxxxxxx, netdev@xxxxxxxxxxx, cryptoapi@xxxxxxxxxxxxxx, Eugene Surovegin <ebs@xxxxxxxxxxx>
In-reply-to: <4184C286.3000400@xxxxxxx>
Organization: jamalopolous
References: <1099030958.4944.148.camel@uganda> <1099053738.1024.104.camel@xxxxxxxxxxxxxxxx> <20041029180652.113f0f6e@xxxxxxxxxxxxxxxxxxxx> <20041030203550.GB6256@xxxxxxxxxxxxxxxx> <20041031010415.4c798a04@xxxxxxxxxxxxxxxxxxxx> <20041030205630.GD6256@xxxxxxxxxxxxxxxx> <20041031012423.74b98698@xxxxxxxxxxxxxxxxxxxx> <1099179687.1041.117.camel@xxxxxxxxxxxxxxxx> <20041031121308.648e98f9@xxxxxxxxxxxxxxxxxxxx> <4184C286.3000400@xxxxxxx>
Reply-to: hadi@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
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.
Come to think of it, this would be really easily doable if the crypto
device appeared to the system as a netdevice.

cheers,
jamal


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