[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> <> <> <> <> <> <1099179687.1041.117.camel@jzny.localdomain> <> <> <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:
> > 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

> 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:
> List archive:
        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>