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

[Yevgeny Kliteynik]

Hi Hal & Sasha.

Hal Rosenstock wrote:
> Hi Yevgeny,
> 
> On Mon, 2006-12-18 at 18:33, Yevgeny Kliteynik wrote:
>> 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?).
> 
> 0 seems better to me but I'm not sure what else this impacts.

Agree.
 
> Note also there are other 0xffff initializations similar to this which
> IMO are also candidates for change :-(
> 
>>       * 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.
> 
> Is is_set really needed ?

No, it's not - I added it just to 'encapsulate' the default value of the
new field, so that this initialization value will remain osm_switch_t internal. 
But we can access the field directly instead.
We can also replace it by something like osm_switch_lmx_exists() to make it look
more general.

>>       * 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.
> 
> Perhaps a dump routine is a routine which each routing protocol should
> supply ?

Good idea. This way the dump function will dump whatever is relevant to 
a certain routing engine.

-- Yevgeny

> -- Hal
> 
>> 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 
>>
>>  
>>
>>
> 
> 
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>