> >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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
