[openib-general] [PATCH] RDMA / IB CM: support immediately sending replies to received messages
Sean Hefty
mshefty at ichips.intel.com
Mon Aug 7 10:21:49 PDT 2006
Or Gerlitz wrote:
> 1) the CM moves the QP state to RTS before sending the REP and hence per
> the QP its fine to do TX before getting the ESTABLISHED event.
Correct.
> 2) if a ULP calls rdma_establish (eg when polling an RX from CQ --> QP
> --> un ESTABLISHED CMA ID or from the COMM_EST case of the qp async
> event handler) it is ensured they will get ESTABLISHED event so its up
> to them if to wait for the event before processing the RX or not.
Note that since the QP is in the RTS state, the IB COMM_EST event will _not_ be
generated. This is the key difference between these approaches. The user would
need to call rdma_establish when polling a RX from the CQ. Failure to do so
would result in a connection failure if the RTU were not received. Calling
rdma_establish would result in an RDMA CM ESTABLISH event.
> OK, fair enough. Personally i preferred the patch set that implemented
> everything within the ib stack and just had this little requirement on
> the ULP to hold on with doing TX before getting the ESTABLISHED event,
> but this one makes sense as well.
My preference is to provide whichever solution makes it easier on the majority
of the ULPs (ignoring spec changes at the moment). I don't know which fix ULPs
will find easier to work with. Maybe we can come up with a compromise where we
expose rdma_establish, but transitioning to RTS before the REP is sent requires
that the ULP do the transition...?
> Also, i understand that for APM support a patch in the spirit of what
> you were suggesting (ie track local QPNs and affiliated QP async events
> in the CM) would be merged anyway, correct?
Correct.
- Sean
More information about the general
mailing list