On Tue, Jul 16, 2002 at 06:14:52PM -0700, cgd@broadcom.com wrote:

 > > I suppose what could be done here is that a per-session list of backends
 > > which can perform the request could be created when the session is
 > > created.
 > 
 > Theoretically, you could have a new back-end added dynamically.

Yah, I think I know how it can be handled, too.

What you'd do is bump a generation number when a back-end is registered
or unregistered.  Then you consult that generation number when assigning
a back-end to a request -- if it's newer than what the session has cached,
then the session needs to refresh its notion of which back-ends exist.

 > yes, defintely allow reassignment to different back-end in the spec.
 > 
 > nail down session-to-hw, but still i think you have to cope when hw
 > disappears.  Could add dynamic load balancing later, "or something."

Yah, my implementation right now doesn't deal with disappearing hardware,
but I don't think anything in the client API as currently spec'd prevents
it.

 > As for _how_ you nail down session-to-hardware: well, this actually
 > touches the client API.  (my opinion w/o thinking about it much would
 > probably be to allow the clients specify approximate bandwidth needs,
 > then query the back-ends for their available bandwidth and assign
 > based on that.  Note query, because back-ends should be able to say
 > "i'm in use for this xform thing and these dmover things, so i only
 > have this much BW left.  I think bandwidth estimates may be
 > ... imprecise and inaccurate... but better than nothing until
 > something better is in place?)

Yah, so my though was to basically build a list of candidates in
the middle-end.  Not so much have the clients specify how much BW
they need, but more allow the back-ends to speicfy how much they
have LEFT.  The one with the most left when a request is scheduled
gets a request.  For things like setkey, you can handle it all lazily
(I just looked at how the existing crypto coprocessors work, and they
all make lazy setkey operations pretty easy to deal with).

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>