[openib-general] OSM: Using lid matrices in ucast manager

Yevgeny Kliteynik kliteyn at mellanox.co.il
Mon Dec 18 15:33:05 PST 2006


Hi Hal.
 
I have a question about some patch that I want to send regarding lid
matrices usage in osm ucast
manager:
 
The FatTree routing doesn't use the min hop tables, so we can skip the
lid matrices building in OSM.
However, ucast manager uses these lid matrices also to get the max lid
that is accessible from each
switch, which defines the LTF table size.
This max lid is obtained by calling osm_switch_get_max_lid_ho()
function, which in turn, calls 
osm_lid_matrix_get_max_lid_ho() for the switch's lid matrix.
If the lid matrices weren't built, then the  osm_switch_get_max_lid_ho()
function will return 0xFFFF,
and eventually osm will crash.
 
Of course, I don't want to build all the lid matrices just to know the
max lid, so here's what I've done:
 
*	I added a field to the osm_switch_t object: max_lid_ho (with
default value 0xFFFF, should it 
be 0x0 instead?).
*	Added and three osm_switch_t methods for this new field: getter,
setter, and is_set that returns
true if this field has been set.
*	The original osm_switch_get_max_lid_ho() has been updated to
return this field value if it's set.
*	Then in FatTree routing I set this field for each switch (I get
the max lid 'for free' as a byproduct
of the algorithm).
*	Now everything in the ucast manager works fine, except for the
following two dump functions:
        __osm_ucast_mgr_dump_ucast_routes (it uses hops)
        ucast_mgr_dump_lid_matrix (obviously...)
These two functions check at the beginning whether the max_lid_ho was
set (using the 'is_set'
method), and return w/o printing anything if the answer is yes.
 
This way any other routing engine that uses lid matrix is not affected
by this change, and any routing 
engine that doesn't use the lid matrix has a way to set the max lid per
switch explicitly.
 
This approach works great, but I have a feeling that this is kinda
hack...
 
What do you think about this solution?
Any other suggestions?
 
Anyway, just wanted to hear your opinion before sending the patch.
   
Regards,
 
Yevgeny Kliteynik
 
Mellanox Technologies LTD
Tel: +972-4-909-7200 ext: 394
Fax: +972-4-959-3245
P.O. Box 586 Yokneam 20692 ISRAEL 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20061219/1c485a48/attachment.html>


More information about the general mailing list