[openfabrics-ewg] [openib-general] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze

[Or Gerlitz]

Tziporet Koren wrote:
> Or Gerlitz wrote:
>> Tziporet Koren wrote:
>>
>>
>>   The bonding package would support: fresh (2.6.20) and some older 
>> upstream kernels along with SLES10 and RH4 Ux (x=3 for sure)
>>
>>   
> OK - please send us all the info once its ready
>>>       General changes to the package:
>>>     * Multicast - we wait for Voltaire and Sean to close all technical
>>>       details - should be ready by the end of the week
>>>     
>>
>> I have just sent Sean over the list a clarification email, if needed 
>> we would be able to help doing the missing patches and i guess in a 
>> combined effort this would be ready for the end of --next-- week
>>
>>   
> Thanks - please work with MST & Vlad on integration
>> what about the host side QoS code? i did not see an newer RFC nor 
>> patch other then the RFC that was sent many months ago.

> We are going to update our low level driver (mthca) to support it. 

> Beside there should be a small change in CMA for this, and its specified 
> in the RFC.

I understand that the change involves letting the rdma cm know the SID 
when the consumer calls --rdma_resolve_route-- where today it get to 
know the SID when the consumer calls --rdma_connect-- . So this is not 
an internal RDMA CM change but rather also changes the API.

Same for SRP as the api of ib_sa_path_rec_get (that is the structure it 
gets as input) changes, the SRP code also changes.

Any, can you send the mthca and rdmacm/rdmacm-consumers changes as 
RFC/PATCH over the list before the actual code freeze???

As for the QoS RFC
(http://openib.org/pipermail/openib-general/2006-May/022331.html) sent 
by Eitan, one design issue I see there is how to deal with IB ULPs which 
do --not-- have a well known SID. So they call ib_cm_listen with 
IB_CM_ASSIGN_SERVICE_ID and get from the CM a service id to use, then 
they might do some out of band exchange of this SID before starting 
their connection establishment.

from include/rdma/ib_cm.h

> * @service_id: Service identifier matched against incoming connection
>  *   and service ID resolution requests.  The service ID should be specified
>  *   network-byte order.  If set to IB_CM_ASSIGN_SERVICE_ID, the CM will
>  *   assign a service ID to the caller.

Typically this happens with MPI up to the extent that different ranks 
within the same job may get a different SID. One solution i was thinking 
of is to

+1 define --range-- (eg big enough to serve 1024 CM consumers) per ULP
+2 change the CM to support allocating SID in a range
+3 change the ULPs which use IB_CM_ASSIGN_SERVICE_ID to ask SID in the 
relevant range
+4 change the QoS manager at the SM side to support ranges

Or.