[openib-general] SA cache design

[Eitan Zahavi]

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.

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