[ofa-general] Re: [PATCH] osm: integer indexes in fat-tree

Yevgeny Kliteynik kliteyn at dev.mellanox.co.il
Mon May 14 04:33:05 PDT 2007


Hi Hal,

Hal Rosenstock wrote:
> Hi Yevgeny,
> 
> On Mon, 2007-05-14 at 03:30, Yevgeny Kliteynik wrote:
>> Hi Hal,
>>
>> Enhancing integer indexes in fat-tree to 32 bits.
>> I'm not sure whether it's a bug - fat-tree routing makes indexing
>> not the same way as up/down. It marks rank on all the leaf switches,
>> and only then starts BFS (starting from all the leaf switches and not
>> from roots), so I don't think that it can really overflow the existing
>> indexes. But who knows...
>> Fixing this won't hurt anyway.
> 
> No, it won't.
> 
>> Please apply to master.
> 
> See comment/question below.
> 
> -- Hal
> 
>> -- Yevgeny
>>
>> Signed-off-by:  Yevgeny Kliteynik <kliteyn at dev.mellanox.co.il>
>> ---
>>  osm/opensm/osm_ucast_ftree.c |   12 ++++++------
>>  1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/osm/opensm/osm_ucast_ftree.c b/osm/opensm/osm_ucast_ftree.c
>> index 7b6a6a5..ca51484 100644
>> --- a/osm/opensm/osm_ucast_ftree.c
>> +++ b/osm/opensm/osm_ucast_ftree.c
>> @@ -174,7 +174,7 @@ typedef struct ftree_sw_t_
>>  {
>>     cl_map_item_t          map_item;
>>     osm_switch_t         * p_osm_sw;
>> -   uint8_t                rank;
>> +   uint32_t               rank;
>>     ftree_tuple_t          tuple;
>>     ib_net16_t             base_lid;
>>     ftree_port_group_t  ** down_port_groups;
>> @@ -588,7 +588,7 @@ __osm_ftree_sw_create(
>>     memset(p_sw, 0, sizeof(ftree_sw_t));
>>  
>>     p_sw->p_osm_sw = p_osm_sw;
>> -   p_sw->rank = 0xFF;
>> +   p_sw->rank = 0xFFFFFFFF;
>>     __osm_ftree_tuple_init(p_sw->tuple);
>>  
>>     p_sw->base_lid = osm_node_get_base_lid(p_sw->p_osm_sw->p_node, 0);
>> @@ -678,7 +678,7 @@ static boolean_t
>>  __osm_ftree_sw_ranked(
>>     IN  ftree_sw_t * p_sw)
>>  {
>> -   return (p_sw->rank != 0xFF); 
>> +   return (p_sw->rank != 0xFFFFFFFF); 
>>  }
>>  
>>  /***************************************************/
>> @@ -1025,7 +1025,7 @@ __osm_ftree_fabric_destroy(ftree_fabric_
>>  /***************************************************/
>>  
>>  static void 
>> -__osm_ftree_fabric_set_rank(ftree_fabric_t * p_ftree, uint8_t rank)
>> +__osm_ftree_fabric_set_rank(ftree_fabric_t * p_ftree, uint32_t rank)
>>  {
>>     if (rank > p_ftree->tree_rank)
>>        p_ftree->tree_rank = rank;
>> @@ -1314,7 +1314,7 @@ __osm_ftree_fabric_assign_first_tuple(
>>     ftree_tuple_t new_tuple;
>>  
>>     __osm_ftree_tuple_init(new_tuple);
>> -   new_tuple[0] = p_sw->rank;
>> +   new_tuple[0] = (uint8_t)p_sw->rank;
> 
> Should the declaration of ftree_tuple_t change ?

Only if there's a chance that we will build a switch with more than 256 ports.
And when I say "switch" I mean a single unit, not the one that has internal
topology with several building blocks.
But in that case lots of things should be fixed.
For instance, ib_node_info_t.num_ports is 8 bits too.

-- Yevgeny

>>     for (i = 1; i <= p_sw->rank; i++)
>>        new_tuple[i] = 0;
>>  
>> @@ -1374,7 +1374,7 @@ __osm_ftree_fabric_calculate_rank(
>>  {
>>     ftree_sw_t   * p_sw;
>>     ftree_sw_t   * p_next_sw;
>> -   uint16_t       max_rank = 0;
>> +   uint32_t       max_rank = 0;
>>  
>>     /* go over all the switches and find maximal switch rank */
>>  
> 
> 




More information about the general mailing list