[openib-general] new IB CM reject reason

[Michael S. Tsirkin]

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

Since we disagree about spec reading, would you raise this in the
relevant WG?

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

And my claim is that you should define private data format to go with this
other reason otherwise you are not really solving the problem.

-- 
MST