[openib-general] [RFC] send side QP redirection

[Hal Rosenstock]

On Fri, 2005-09-16 at 17:27, Sean Hefty wrote:
> I'd like to get feedback about a possible implementation for requester QP 
> redirection based on the APIs given below.

>   Specifically, I'm referring to GSI 
> redirection (spec 13.5.2) and port and CM redirection (REJ code 24).
> 
> The basic proposal is to combine QP redirection as an extension to an address 
> handle cache.  Remote agents are identified by management class, LID, and GID.

> struct ib_mad_av {
> 	struct ib_ah *ah;
> 	u32 remote_qpn;
> 	u32 remote_qkey;
> 	u16 pkey_index;
> };

What about SL and the other redirect GRH fields (TC and FL) ?

> /*
>   * Insert a new destination into the map and create a new address
>   * vector to it.  If the destination already exists, simply return
>   * the current address vector.
>   * /
> struct ib_mad_av* ib_insert_mad_dest(struct ib_mad_agent*,
> 				     struct ib_ah_attr*,
> 				     mgmt_class, lid, gid, pkey);

So the last three parameters are transferred from the received
ClassPortInfo.

> struct ib_mad_av* ib_get_mad_av(struct ib_mad_agent*,
> 				mgmt_class, lid, gid);

I'm missing why LID and GID are needed here and why pkey is missing.
Is there more than 1 struct ib_mad_av allowed per mgmt_class ?

> /*
>   * TBD: need to determine when to remove a destination.  Can remove
>   * always if references go to 0.  Can add a delay before removal.  Can
>   * maintain destinations that have been redirected. ?
>   */
> void ib_free_mad_av(struct ib_mad_av*);
> 
> ib_redirect_mads(struct ib_mad_av*, struct ib_mad_recv_wc*,
> 		 struct ib_class_port_info*);
> 
> /* GID redirection with unknown LID would be deferred */
> int ib_get_mad_redirect_path(...);

Just curious why ?

> Questions or thoughts?

Is multiple redirection handled by this ?

Would these semantics need to be extended to user space by user_mad ?

-- Hal