Subject: Re: crypto framework and dmover?
To: Jason Thorpe <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 07/28/2003 19:54:11
In message <>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 

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.  ]]