Actually, I was thinking about returning an error from the REP/REQ handler, this I believe is suppose to destroy the communication identifier, which I presume will generate a REJ? This is at least the behaviour I would like to see. In this case, since the communication identifier is destroyed there wouldn't be any other state transitions.
This is the current behavior.
Yet another issue. Saving the info from the incomming CM message, specifically REQ and REP, for later QP transitions is something that's going to be duplicated quite a bit. I would really like to see this data in the communication identifier itself, so it can be plucked out later for the QP modifies. To take it one step further, Roland had the suggestion, that it would be really nice to have CM conveniance functions, to which you pass a cm_id and qp_attr structure and it assigns all the correct values and masks for a given transition. For example:
int ib_cm_prep_rtr(struct ib_cm_id *, struct ib_qp_attr *); int ib_cm_prep_rts(struct ib_cm_id *, struct ib_qp_attr *);
I just had a conversation this morning with someone about this exact same functionality. I think that it makes sense to add these routines. (The exact format/parameters for the API may need to be slightly different.)
- Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
