Michael S. Tsirkin wrote: > Quoting r. Tom Tucker <[EMAIL PROTECTED]>: >> So... all that said, I could in fact support rdma_reject on an active >> side connection. But this would effectively reduce to a QP --> ERROR >> and I doubt this matches the semantics you're looking for. > > Why not? Sounds good.
Three points: 1) On iWARP this is really an operation on the QP. The cm_id is an artifact of the callback interface, and this reject would be at a point where no further callbacks were needed. It seems strange to request that the application keep this around just for this purpose. 2) The private data supplied will not be delivered. It's unreliable over IB CM, but with iWARP it is reliably never delivered. That's something that the user should at least be told somehow. 3) This is slightly askew from DAPL and IT-API two-way semantics, where the destruction of the connection request is implicit. There's nothing inherently wrong with this, but it should be highlighted so that the wrong expectations are not inferred by readers incorrectly. With those caveats, what you are suggesting is a transport neutral method of abruptly terminating a connection which when used immediately over IB also delivers private data to the other end. I suppose that with the proper caveats and documentation there really isn't any problem with that. I would prefer that the iWARP implemenetation not be required to enforce that the reject call be made *immediately*, because that would be an extra step. Instead the rdma_reject call would be accepted anytime after the MPA Response is received and the cm_id is reassigned or released. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
