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

[Michael S. Tsirkin]

> Quoting Or Gerlitz <ogerlitz at voltaire.com>:
> 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