[openib-general] SA cache design

[Eitan Zahavi]

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.

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