Subject: Re: crypto framework and dmover?
To: Jason Thorpe <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 07/28/2003 19:54:11
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
>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
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. ]]