iWARP/MPA and iWARP/SCTP both distinquish between a rejection that came from the ULP peer and one that came from the stack (including the RDMA layer).
A TCP rejection is definitely a Non-peer rejection. But it is also a non-peer rejection if the connection request cannot be delivered to the remote peer for approval. Reasons for that would include not having the resources, or the quota, to deliver the connection request to the user (particularly plausible if the remote peer that must approve the connection request is in user mode). This is distinquished in the response header (MPA or SCTP). > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier > Sent: Tuesday, September 20, 2005 2:27 PM > To: Sean Hefty > Cc: Openib > Subject: Re: [openib-general][PATCH][RFC]: CMA header > > Sean> From an implementation viewpoint, I'm not sure we can > Sean> distinguish between rejected and peer rejected. How about > Sean> just rejected with some additional reject information in the > Sean> case that the user cares? > > I think the right way to think of this API is as implementing > an iWARP emulation layer for IB. For a TCP connection, > there's only one "rejected" status, ie ECONNREFUSED. So I > don't think we can expose multiple reject reasons or > additional reject data. > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
