[openib-general] CM and REP handling

[Rimmer, Todd]

> From: openib-general-bounces at openib.org
[mailto:openib-general-bounces at openib.org] On Behalf Of Viswanath
Krishnamurthy
> Sent: Friday, June 30, 2006 1:26 PM



> In the current communication manager (CM) implementation how is the
REP MAD
> getting lost handled. When the REP gets lost, the cm_dup_req_handler
gets called
> which currently enters the default condition and does nothing.  The
client retries 
> the number of timers it is configured to and fails.  If the first REP
gets lost, the connection
> never gets established. So what should be the behavior ?

The IBTA standard in section 12.9.7 defines this situation in the state
machine.

 

In this case the Active side will have sent a REQ.  It will be in REQ
Sent state (or REP Wait in passive side sent an MRA).  In these states
the Active side will have a timer running.  If the REP is lost, the
Active side will timeout and move to the "Timeout" state.  In this
state, the active side has the option of resending the REQ or sending a
REJ and giving up on the connection attempt. In general it is best for
the active side to perform a few retries before it gives up.

 

During this sequence the passive side will think it has sent its REP
(eg. the one which was lost) so it will be in the REP Sent state (see
12.9.7.2).  In this state if it receives another matching REQ, it is to
resend its REP.  There is also a timer on the passive side in this state
(waiting for the RTU).  If the passive side times out it will move to
RTU Timeout and has the option to resent its REP or send a REJ and give
up the connection attempt.  Here too it is best for the passive side to
perform a few retries before giving up.

 

Todd Rimmer

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20060630/11f9cb8b/attachment.html>