[openib-general] [PATCH] CM: new call to return QP attributes for use modifying the QP

Sean Hefty mshefty at ichips.intel.com
Wed Jan 26 11:26:30 PST 2005


Libor Michalek wrote:
>   On the passive connect side the RTR QP transition needs to occur before
> the REP message is sent. One of the valid states for ib_cm_init_qp_attr()
> RTR states change is REQ_RCVD. Obviously in this case there is no 
> starting_psn from the REP... 

I've swapped where sq_psn and rq_psn are stored, and renamed the 
starting_send_psn field in the CM parameters to just starting_psn.

The rq_psn is now stored when sending the REQ or REP, and sq_psn is 
stored when receiving the REQ or REP.  As you pointed out though, the 
passive side rq_psn is needed for REP is sent...

* The user could be responsible for setting the rq_psn on the passive 
side before modifying the QP.  The user would still need to provide 
this value when sending the REP.  This option makes it more difficult 
on the user.

* The CM could make up a PSN value (similar to the Topspin 
ib_cm_psn_generate call) and return it to the user through the QP 
attributes.  The user would need to extract the returned value and 
provide it when sending the REP.  The value would need to be returned 
by users that did not call the CM helper function.

* The CM could just hide the PSN value from the user entirely.  This 
requires users to call the CM helper function.

So far, I'm not caring for any of the options that I can think of.

- Sean



More information about the general mailing list