I've not read the new version yet...  i'll comment on it ASAP.

At Wed, 10 Jul 2002 08:26:46 -0700, Jason R Thorpe wrote:
>  > * the load balancing algorithm, etc., seems a bit ad-hoc.
>  >   additionally, static assignments of sessions to back-ends for all
>  >   times also seems limiting.  why restrict by describing it that way?
>  > 
>  >   random thought that popped into my head: if you have some kind of HW
>  >   assist module which gets removed from the system (!!), in current
>  >   scheme all dmover clients who happened to have their sessions
>  >   assigned to that module will need to squish and create sessions
>  >   anew.
>  > 
>  >   requirement that hw be used first is kinda lame...  what if your xor
>  >   engine is maxed out but you've got a dual-processor system that's
>  >   idle waiting on xors to finish?
> 
> So, the issue here is that you want to avoid having to look up which
> device can handle your request each time you want to issue one.

yes, quite.


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


> This gets problematic with xform, unfortunately.  Many devices require
> a "constructor" type operation to be performed when a session is created
> (allocate some data structure, etc.), and then there's the issue of the
> "setkey" operation, as well.  I suppose the hardware-specific session
> creation could be done lazily, however...
> 
> Perhaps a good interim step is to allow for the load-balancing to happen
> in the spec, but still nail down session-to-hardware in the first version
> of the code.

So, I'd say two things to this:

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

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?)



chris