On Sun, Dec 21, 2008 at 4:58 AM, PAPADIMITRIOU Dimitri <[email protected]> wrote: > I meant that the working set is extracted/derived from the BGP routing > database. > > To remove the confusion, I suggest to consider i) pull from local > database (e.g. BGP RIB) - one could refer to local pull, ii) pull from > remote databases (e.g. DNS) - one could refer to remote pull, and as I > stated in my previous post iii) "hybrid pull-push" to cover the case of > proactive cases. > > Would that work for you ?
Hi Dimitri, Not really, no. Are you aware of any examples of a cache coupled with a BGP RIB? Generally we see a full database conversion to produce the local FIB and we see direct queries for diagnostics such as a looking glass. On occasion we also see defined database subsets propagated towards a peering-only router. None of these activities exhibit the characteristics commonly understood to be a cache. If no such system exists, we can hardly report on its operational properties. The key elements of the matrix seem to be: * Pull, pull with extra, speculative push. All caching systems exhibit pull, pull with extra or both. Some also have speculative push. Example of pull: ARP request and response. Example of pull with extra: DNS request and response with "additional" section. Example of speculative push: cache page invalidation due to a write to another CPU's cache in a multi-CPU system. * Local database, remote database. The major difference between a local database and a remote database is that lookups to a local database are expected to succeed with a high enough probability of success that it can be considered a critical-stop failure when they don't succeed. Example of a local database: DRAM on a computer. Example of a remote database: DNS. * Central database, distributed database. Example of a central database: A SQL server. Example of a distributed database: Virtual memory: multiple swap files on different hard disks. Note that some virtual memory architectures treat DRAM as a cache for virtual memory while others treat DRAM as one element in a distributed database. For the former, the swap must be at least as large as the DRAM and the swap page is allocated at the same time as the DRAM page. In the latter, space in the swap file is not allocated until you want to remove a page from DRAM. > -> Associativity (Direct mapping, Fully/N-Way/Skewed) Can you offer examples of associativity outside of CPU caches? The ones you've mentioned here are all very specific to issues that arise when trying to deal with mapping CPU cache pages to DRAM pages. Regards, Bill Herrin -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
