[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