Hi Ira, On 11:43 Thu 25 Oct , Ira Weiny wrote: > As I said in another thread. I have added switch-map support to opensm. This > patch series does that in a number of steps. > > Patch: > 1) Simple comment fix (Should be applied on it's own regardless of if the > series is accepted.) > 2) Moves the switch map support to ibcommon but leaves the implementation > alone.
(hmm, I thought to remove (split between libibumad and libibmad) libibcommon after OFED-1.3 in order to reduce number of management packages, it is not 100% necessary step however.) > 3) Changes the implementation of the switch map to read the file into > memory > to facilitate faster lookups as well as multi-threaded lookups. > 4) Add the switch map calls to opensm but leave the creation of the switch > map to be the default one provided by ibcommon (Pass NULL to > create_switch_map) > 5) Add an option to the opts file to specify a switch map. > 6) Allow a special value of "(null)" in the opts file. (This too could be > applied outside of the series.) Thanks for the patches. I applied 1 and 6 and have some thoughts about others: 1. If we are doing naming map, why it should be limited from beginning for switches only. I would prefer to extend it to any node types (since "guid name" records are optional, it will work as "switches only" just well). Actually I can see that in OpenSM related patch it is done for any node. Probably then we need another than "switch-map" name, what about "guid2name-map" or "nodename-map"? 2. In-memory optimization is good thing, but lookup still be linear and slow. It is probably acceptable for diags (for most - only few nodes should be resolved), but at least for OpenSM I think name_by_guid qmap approach is preferable. What do you think? Sasha _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
