Subject: Re: crypto framework and dmover?
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Sam Leffler <firstname.lastname@example.org>
Date: 07/29/2003 09:51:47
--On Monday, July 28, 2003 7:54 PM -0700 Jonathan Stone
> 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
> 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.