[ofa-general] [PATCH] opensm/osm_ucast_ftree.c: some refactoring

[Yevgeny Kliteynik]

Nicolas Morey Chaisemartin wrote:
> Hi,
> 
> Are you sure of this?
> Seems to me as if there is a problem
> Yevgeny Kliteynik wrote:
> 
> ...
> 
> Function is setting hops value for the origin ports of the given port group on the given switch
>>  /***************************************************
>> @@ -2027,19 +2040,11 @@ fabric_route_upgoing_by_going_down(IN ftree_fabric_t * p_ftree,
>>
>>  			/* On the remote switch that is pointed by the p_group,
>>  			   set hops for ALL the ports in the remote group. */
>> -
>> -			for (j = 0; j < ports_num; j++) {
>> -				cl_ptr_vector_at(&p_group->ports, j,
>> -						 (void *)&p_port);
>> -
>> -				sw_set_hops(p_remote_sw,
>> -					cl_ntoh16(target_lid),
>> -					p_port->remote_port_num,
>> -					((target_rank - highest_rank_in_route) +
>> -					 (p_remote_sw->rank - highest_rank_in_route)
>> -					 + reverse_hops * 2));
>> -			}
>> -
>> +			sw_set_hops(p_remote_sw,
>> +				cl_ntoh16(target_lid), p_group,
>> +				((target_rank - highest_rank_in_route) +
>> +				 (p_remote_sw->rank - highest_rank_in_route) +
>> +				 reverse_hops * 2));
>>  		}
> 
> Here you call the function wth the remote switch and a local port group.
> So if I'm write the port num you use on the function are the port num on p_sw and not p_remote_sw...

Oh, you're right. Thanks. I'll fix it.

> The remote port group should be pass to this function but I don't think we have an easy way to get it.
> Other solution could be to factorize the code in another function which would call sw_set_hops and provide it the right port num.
> 
> Anyway, how is the hops table used?
> In the ftree algorithm, it seems we only use the min value through osm_switch_get_least_hops so we don't use the fact that there can be multiple values.
> If it has no use in the Ftree algorithm, is it worth spending time to set all the hop values ?

Hops tables are used for multicast routing, so if the matrix
is not full, there will be more bottlenecks in multicast routes.

-- Yevgeny
 
> 
> Nicolas
>