[openib-general] SA cache design

[Hal Rosenstock]

On Fri, 2006-01-06 at 15:13, Eitan Zahavi wrote:
> Hal Rosenstock wrote:
> > On Fri, 2006-01-06 at 15:00, Eitan Zahavi wrote:
> > 
> >>I agree with Todd: a key is to keep the client unaware of the mux existence.
> >>So the same client can be run on system without the cache.
> > 
> > 
> > Define same client ? I would consider it the same SA client directing
> > requests differently based on how the mux is configured based on a query
> > to the cache (if it exists) as to its capabilities.
> SA Client can be embedded in an application - any program that can send mads 
> can be an SA client.

Such (non OpenIB) clients would not take advantage of the cache. That
seems like the tradeoff for not the duplicated forwarding of the
request. Guess I'm in the minority thinking that this might be
worthwhile.

-- Hal

> 
> > 
> > -- Hal
> > 
> > 
> >>Hal Rosenstock wrote:
> >>
> >>>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
> >>>
> >>>_______________________________________________
> >>>openib-general mailing list
> >>>openib-general at openib.org
> >>>http://openib.org/mailman/listinfo/openib-general
> >>>
> >>>To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
> >>
>