[openib-general] Re: DAPL CM Reject Questions

[James Lentini]

> Hal Rosenstock wrote:
>> On the passive side, an RTU is received but the QP cannot be transition
>> to RTS so a REJ is attempted as below:
>> 
>> static int do_rtu_recv(struct dapl_cm_id *conn)
>> {
>>         int status;
>> 
>>         status = dapl_modify_qp_state_to_rts(conn->cm_id, 
>> conn->ep->qp_handle);
>>         if (status) {
>>                 dapl_dbg_log(DAPL_DBG_TYPE_ERR, " do_rtu_recv: could not "
>>                              "modify QP state to RTS status %d\n", status);
>>                 goto reject;
>>         }
>> 	...
>> 
>> reject:
>>         ib_send_cm_rej(conn->cm_id, IB_CM_REJ_CONSUMER_DEFINED, NULL, 0,
>>                        NULL, 0);
>
> This should call ib_send_cm_dreq(), rather than a reject.

I've changed the above line to

(void) ib_send_cm_dreq(conn->cm_id, NULL, 0);

in revision 2329.

>> If RTU is received, the connection would be in ESTABLISHED state. Is
>> sending REJ valid there ? What's odd to me is that the CM state machine
>> in the IBA spec shows REJ being received in the established state on the
>> active side (and moving to TIMEWAIT) but there is no action out of
>> established on the passive side showing send REJ.
>
> On the passive side, the user can time out waiting for an RTU and issue a 
> reject.  But the RTU may have been sent (and lost) on the active side.  So, 
> the active side would be in the ESTABLISHED state when the REJ is received.
>
> This cannot happen on the passive side.
>
>> If sending REJ is valid on the passive side in established state, does
>> the current CM handle this ? It looks to me like it returns -EINVAL for
>> this case.
>
> See above...  I think that the CM code is correct, and my kDAPL 
> implementation is in error.

Were either of you going to work on a fix for this?