On Mon, Mar 19, 2007 at 02:29:25PM -0700, Sean Hefty wrote:
> Based on previous e-mail threads, this is my plan for implementing IB-to-IB
> router support in the host stack capable of supporting RC communication. Note
> that this work is part of the PathForward project aimed at supporting early
> IB-to-IB router development. It is not intended to define IB router
> architecture.
Would it become part of openfabrics or just as a 3rd party
patch that interested parties could apply?
> 1. Extend struct ib_cm_req_param:
>
> struct ib_cm_req_param {
> struct ib_sa_path_rec *primary_path;
> struct ib_sa_path_rec *alternate_path;
> + struct ib_sa_path_rec *remote_primary_path;
> + struct ib_sa_path_rec *remote_alternate_path;
So the idea is that the CM REQ now uses remote_*_path to set the
fields? You intend to go with the notion that IBA specifies the
active sides sets the passive's LIDs in all cases?
> 2. Add an ib_remote_sa module.
It looks like there is a new wire protocol to support this?
Does it still work if, for instance, a modified active side tries to
talk to an arbitary existing target (such as storage or something)?
Broadly, do you describe having the active side send a seperate GMP to
the passive node to do PR queries and then sending a CM REQ?
> 3. Extend the rdma_cm route resolution to include remote route lookup.
This means produce a ib_cm_req_param using ib_remote_sa when
appropriate right?
How does this compare to the idea of using the LIDs from the REQ's LRH
on the passive side?
Thanks,
Jason
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
