[ofa-general] Re: [PATCH 0/6] Add Switch Map support to opensm
Sasha Khapyorsky
sashak at voltaire.com
Sat Oct 27 10:52:27 PDT 2007
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
More information about the general
mailing list