--On Monday, July 28, 2003 7:54 PM -0700 Jonathan Stone 
<jonathan@DSG.Stanford.EDU> wrote:
> In message <100ABF92-C167-11D7-8E37-000A957650EC@wasabisystems.com>Jason
> Thorpe writes
>>
>> On Monday, July 28, 2003, at 05:56  PM, Matt Thomas wrote:
>>
>>> How does, if at all, the new crypto framework and the dmover framework
>>> interact/intersect?
>>
>> They don't, really.  And that's okay, in my opinion.
>
> IIRC,  we reached agreement on both points  some time back, too.
>
>> I would, however, really like to see "crypto" be a more generic
>> "transformation" framework, that could e.g. handle things like MPEG
>> encode/decode, etc.  I would also like the crypto framework to use a
>> dmover-like scheduling engine and algorithm looking mechanism (using
>> strings).
>
> This could get a litlte more controversial.
>
>
> For myself, I'd much sooner liek the crypto framework to handle
> scheduling amongst multiple hardware cyrpto devices; first homogenous
> (where round-robin or shortest-queue first is "good enough") then with
> disparate cards.
> 	<...stuff deleted...>

FWIW, I've done some work on a multi-driver scheduler for the crypto 
framework.  The two main goals were to load balance across identical parts 
(e.g. where you can share state) and load balance across parts with very 
different performance characteristics.  The latter is mainly to permit 
small crypto requests to be processed in s/w rather than always dispatching 
them to a h/w device, but it can also be used to more effectively utilize 
devices with disparate performance. The scheduler uses metrics that are 
calculated at device attach.  The results look promising but the work is 
unfinished and won't get touched for a while.

Otherwise, if you're looking for things to do to improve the crypto 
framework; add support to make use of protocol-specific (e.g. IPsec) 
processing by h/w devices.

	Sam