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