On 1/17/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote: > > Quoting Or Gerlitz <[EMAIL PROTECTED]>:
> > 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. the rdmacm api change is not such a big deal and if you want to change it only for the kernel portion for the ofed 1.2 it makes sense to me. I really don't think --adding-- a special api is the way to go. Doing it in "end in mind" fashion, work on a patch, send it to the rdmacm maintainer/list for RFC and so on. > 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. SDP is coded over the RDMA CM and i say above my suggestion is not to add a special API, so just dp the same QoS patching you do to SDP to iSER etc. 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
