Ready to Receive State
Under Software Control, RTR Is Entered From...
...the Initialized state. Software transitions a QP from the Initialized state to the RTR state using the Modify QP verb call.
RTR State Operational Characteristics
When a QP is in the RTR state, it has the following operational characteristics:
WRs can be posted to the RQ.
Inbound message transfer request packets can be handled.
The first request packet of a Send operation or an RDMA Write With Immediate operation targeting the QP is processed normally by the next RQ WQE. If it's a RC or RD QP, this includes generating an Ack (or a Nak) for the request packet received.
Transition into the RTR state is only possible from the Initialized state via execution of the Modify QP verb.
The RTR state can be exited by executing a Destroy QP (exits the state diagram) or by commanding it (via the Modify QP verb) to change to the RTS, Error, or Reset state.
If the HCA supports RD and the RD QP is currently in the RTR state and software posts a WR to the SQ of the QP specifying a local EEC that is currently in the RTR state, then the WR is completed in error (because the EEC is not ready to send packets for any of its client RD QPs).
SQ WQE processing is disabled. Posting WRs to the SQ results in the return of an immediate error.
Next State (via software command) = RTS
From the RTR state, software would typically transition the QP to the Ready To Send (RTS) state. To do so, software executes the Modify QP verb call and supplies the input parameters defined in Table 12-4 on this page. If software only intends to receive messages over this QP and never intends to send messages through it, software could leave the QP in the RTR state.
Note that using the Modify QP verb, software can also command the QP to enter the Reset or the Error state.
| Input Parameter(s) | Applicable QP Types | Required? | Description |
|---|---|---|---|
| HCA Handle | All | Yes | Returned by earlier Open HCA verb call. |
| QP Handle | All | Yes | Returned by earlier Create QP verb call. |
| Next State | All | Yes | In this case, the RTS state. |
| Local Ack Timeout | RC | Yes | Time QP's SQ Logic waits for Ack before it retries transmission of corresponding request packet. |
| SQ Start PSN | RC, UC, UD | Yes | This is the start PSN assigned to this QP's SQ Logic by software. It will be inserted into the BTH:PSN field in the first request packet generated by the SQ Logic. |
| Retry Count | RC | Yes | Number of times QP's SQ Logic retries transmission of request packet due to either Ack timeout, or receipt of Nak from remote QP's RQ indicating it detected missing packet (i.e., a request packet was received with a PSN > the ePSN). |
| RNR Retry Count | RC | Yes | Supplied by remote CA's CM when two QP's first set up. Defines how many times this QP's SQ Logic should retry transmission of request packet that receives RNR Nak from remote QP's RQ Logic. Remote QP's RQ Logic responds to request with RNR Nak if temporarily unable to handle request. Classic example: Send or RDMA Write With Immediate request packet received and no WQEs posted to receiver's RQ to handle inbound request. |
| Depth of remote QP's special queue for RDMA Read/Atomic operations | RC and RD | Yes | Depth of remote QP's special queue for receiving inbound RDMA Read/Atomic operations from this QP's SQ Logic. |
| Enable/disable RDMA and Atomic Operations | RC, RD, UC | No |
|
| Q_Key | RD and UD | No | See the description of the Q_Key parameter in Table 12-2 on page 238. |
| Alternate path address information | RC and UC | No | See the description of this parameter in Table 12-3 on page 241. |
| Path Migration State | RC, UC, RD | No | For a complete description, refer to “Automatic Path Migration” on page 575. |
| New SQ and/or RQ size | All | No | If HCA supports resizing of the SQ and RQ:
|
| Minimum RNR Nak Timer Field | RC and RD | No | See the description of this parameter in Table 12-3 on page 241. |