[openib-general] RE: rdma_cm.h: comment nits.

[Caitlin Bestler]

Michael S. Tsirkin wrote:
> Quoting r. Tom Tucker <tom at opengridcomputing.com>:
>> 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.