[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