[openib-general] SA cache design

Eitan Zahavi eitan at mellanox.co.il
Wed Jan 11 07:41:46 PST 2006


Hi Sean,

Now I really lost you:

Is the intention to speed up SA queries?
Or is it to have persistent storage of them?

I think we should focus on the kind of data to cache,
how it is made transparently available to any OpenIB client
and how/when is it invalidated by the SM.
We should only keep the cache data in memory not on disk.

Later if we want to make it persistent or even stored in LDAP/SQL...
I do not care. But the first implementation should be in memory.

BTW: most of the databases referred by these mails are not supporting
distributed shadow copies of a centrally controlled tables.

Eitan

Sean Hefty wrote:
> Sean Hefty wrote:
> 
>> To keep the design as flexible as possible, my plan is to implement 
>> the cache in userspace.  The interface to the cache would be via 
>> MADs.  Clients would send their queries to the sa_cache instead of the 
>> SA itself.  The format of the MADs would be essentially identical to 
>> those used to query the SA itself.  Response MADs would contain any 
>> requested information.  If the cache could not satisfy a request, the 
>> sa_cache would query the SA, update its cache, then return a reply.
> 
> 
> What I think I really want is a distributed relational database 
> management system with an SQL interface and triggers that maintains the 
> SA data...  (select * from path_rec where sgid=x and dgid=y and pkey=z)
> 
> But without making any assumptions about the SA, a local cache could 
> still use an RDMS to store and retrieve the data records.  Would 
> requiring an RDMS on each system be acceptable?  If not, then writing a 
> small, dumb pseudo-database as part of the sa_cache could provide a lot 
> of flexibility.
> 
> - Sean
> _______________________________________________
> 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