[openib-general] new IB CM reject reason

[Sean Hefty]

>Would you be interested in a patch making it possible to enable logging CM
>errors
>and/or all CM events?

A patch for this would be fine with me.

>Are we talking about code 28? My spec lists it as "consumer reject".
>The meaning of *private data* is consumer defined.
>
>                   The consumer decided to reject the communica-
>                   tion or EE context setup establishment attempt for
>                   reasons other than those listed in the other REJ
>                   codes. Typically this happens based upon infor-
>                   mation being conveyed in the PrivateData field of
>                   a message. It can also happen because the Con-
>                   sumer decided for reasons unrelated to any CM
>                   message it received to terminate the communica-
>                   tion or EE context setup establishment attempt.
>                   This would therefore be the appropriate Reason
>                   code to use if the Consumer decided to destroy
>                   the QP or EEC in the midst of the communication
>                   or EE context setup establishment attempt.
>
>So this really *does* seem to be what spec intended for exactly our case.

I disagree.  This is for the CM consumer, not the CM itself.  In this case, the
CM must issue a reject that will be delivered to the remote application.  The CM
has no idea what private data format the remote application expects.

>Now, I do not really object to inventing new rejection reasons: for example,
>maybe we can invent one that lets us stick the errno value in private data
>somehow - but it's not like there's no solution inside the spec,
>and inventing a whole new reject reason just for userspace consumers
>seems like a narrow approach to me.

Unless we start enforcing a policy that kernel consumers must issue a reject
before destroying a cm_id (while in the connecting phase), they have this
problem.

My claim is that the reject reasons are insufficient to cover all possible
conditions, and adding a generic 'other' reject reason solves this.  Using
consumer defined, which is what is done today, is incorrect.  As an alternate
solution, we could also not send any reject and just let the connection time out
on the remote side.

- Sean