[openib-general] SA cache design

[Hal Rosenstock]

On Fri, 2006-01-06 at 09:05, Rimmer, Todd wrote:
> > From: Hal Rosenstock [mailto:halr at voltaire.com]
> > On Thu, 2006-01-05 at 18:36, Rimmer, Todd wrote:
> > > This of course implies the "SA Mux" must analyze more than just 
> > > the attribute ID to determine if the replica can handle the query.  
> > > But the memory savings is well worth the extra level of filtering.
> > 
> > If the SA cache does this, it seems it would be pretty simple 
> > to return
> > this info in an attribute to the client so the client would 
> > know when to
> > go to the cache/replica and when to go direct to the SA in the case
> > where only certain queries are supported. Wouldn't this be 
> > advantageous
> > when the replica doesn't support all queries ?
> 
> Why put the burden on the application.  give the query to the Mux.

That's what I'm suggesting. Rather than a binary switch mux, a more
granular one which determines how to route the outgoing SA request.

>   With an optional flag indicating a prefered "routing" (choices of: to SA, 
> to replica, let Mux decide).  Then let it decide.  As you suggest it may 
> be simplest to let the Mux try the replica and on failure fallback 
> to the SA transparent to the app (sort of the way SDP intercepts 
> socket ops and falls back to TCP/IP when SDP isn't appropriate).

It depends on whether the replica/cache forwards unsupported requests on
or responds with not supported back to the client as to how this is
handled. Sean was proposing the forward on model and a binary switch at
the client. I think this is more granular and can be mux'd only with the
knowledge of what a replica/cache supports (not sure about dealing with
different replica/caches supporting a different set of queries; need to
think more on how the caches are located, etc.). You are mentioning a
third model here.

-- Hal