[openib-general] Re: DAPL CM Reject Questions

[Sean Hefty]

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.

> 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.

- Sean