[openib-general] SA cache design
Hal Rosenstock
halr at voltaire.com
Fri Jan 6 12:03:38 PST 2006
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.
-- 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
>
More information about the general
mailing list