>Ok, but, by that time we can keep the framework ready? I plan on re-submitting the cache for 2.6.23. Beyond that I won't have the time to work on enhancements for a few weeks. I will happily review any patch submissions though.
>How this will be managed? This will add extra startup time in the >cluster, because cluster will be usable only after last cache has been >enabled. Am I right? I would word this differently: we can improve the time required to load the cache, versus stating that the cache adds extra startup time. The cache is not necessary to use the cluster, so doesn't force extra startup time. Cache misses would simply be forwarded directly to the SA. If the first application to run on the cluster isn't establishing all-to-all communication between the nodes then there may not be any reason to delay starting the app. Even if the first app does establish all-to-all communication, waiting for the caches to load can delay the start of the app, but cache use may decrease the overall execution time of the app by more than this delay. (Loading the cache is likely to be more efficient than applications obtaining the path records themselves.) >How multi-pathing is handled in current cache_module? A kernel ULP can request all paths, then select the one they want. Beyond that, the cache can either return paths to the user round robin or randomly, based on the cache settings. - Sean _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general