[openib-general] [openfabrics-ewg] Minutes for January 15, 2007 teleconference about OFED 1.2 development progress toward code freeze
ogerlitz at voltaire.com
Wed Jan 17 04:38:52 PST 2007
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
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.
> * @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
+4 change the QoS manager at the SM side to support ranges
More information about the general