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.

One of the important (key?) features of the crypto framework is how
handles both ``lightweight'' continuations (where the continuation is
sufficiently lightweight to be called from hardware-interrupt context0
and more heavyweight continuations, which are deferred to a
software-interrupt callout or (in OpenBSD) a kthread. And moreover,
that this is all implemented efficiently.

For the specific cases IPsec acceleration (and, IIRC, ssl/tls): a
string-based namespace is pretty darn useless when the client
protocols *already* define a namespace of small binary integers to
represent crypto transfors.  

I'm not sure how relevant either one is to MPEG. Unless you're
thinking of a hadware MPEG decoder, with multiple separate clients,
each playing different mpegs in separate windows, on a single machine?

[[Just for myself, and definitely in blue-sky mode: I've wanted for
years to rework some of the current thread-based mechanisms with
continuation-based mechanisms: say for waiting on buffers for I/O
completion on buffers; or for a context-switch-free, aio-thread-free
sendfile()/splice() like the one I implemented one summer at WRL.

To put it another way: if we had a generalized continuation-passing
framework, with a uniform way to request handoffs to callouts or threads,
MPEG and dmover and the crypto framework could *all* use that framework.  ]]