> Quoting Or Gerlitz <[EMAIL PROTECTED]>: > Subject: Re: [openfabrics-ewg] Minutes for January 15, 2007 teleconference > about OFED 1.2 development progress toward code freeze > > 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???
I didn't start on this code yet, but it does not look like a huge project, I hope to post code by next week. To avoid major disruptions all over the stack, my preference for OFED 1.2 would be to add new API calls and a module option (off by default) for cma/srp to use them. > 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 For OFED 1.2, I only planned to implement this for SDP and SRP. I do not expect all this to be mergeable in 2.6.21 time frame, so maybe that's enough. So I think I'll opt for an easier +5 don't set SID in path record query for userspace apps -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
