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
> 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.
> Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi
> List archive: http://lists.logix.cz/pipermail/cryptoapi
Crash is better than data corruption. -- Art Grabowski
Description: This is a digitally signed message part