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

[Or Gerlitz]

On 1/17/07, Michael S. Tsirkin <mst at mellanox.co.il> wrote:
> > Quoting Or Gerlitz <ogerlitz at voltaire.com>:

> > 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.