UC Transport Service Type's Basic Characteristics

UC is a subset of the RC protocol. The responder's RQ Logic doesn't Ack or Nak each request packet it receives.

• Disadvantage: The requester has no verification that each request packet has been received by the remote QP's RQ Logic.

• Advantages:

  - This protocol generates considerably less network traffic than RC.

  - From the sender's perspective, the message transfer completes quickly (because it doesn't have to wait for the transfer to be acknoweldged).

The basic characteristics of the UC service type are:

• Connection needed. Just like the RC protocol, before any messages may be transferred, a connection must be established between the UC QPs in the two adapters, and the QP Contexts of the two QPs are each programmed with the identity of the remote QP as well as the address of the port behind which it resides. Refer to “RC/UC Connection Establishment” on page 186 for a description of the connection establishment process. Also refer to “Communications Management” on page 1069.

• Private communications channel. Just like the RC protocol, the two UC QPs may then be used to send messages to each other (but not to any other other QP in the same or any other CA).

• Message size. Just like the RC protocol, each message can be anywhere from 0 to 2GB in size. Messages large than one PMTU are segmented into multi-packet transfers. It should be noted that a 0-byte Send or RDMA Write is permitted.

• No Ack/Nak protocol. Unlike the RC protocol, there is no Ack/Nak protocol. The requester (i.e., the QP SQ Logic sending the message) therefore cannot verify that each packet is delivered to the responder (the target QP's RQ Logic).

• Software completion notification. There are no responses returned by the remote QP's RQ Logic when using the UC transport service type. That being the case, software on the sender's side is alerted that a message transfer has completed immediately upon the transmission of the last request packet of the Send or RDMA Write. RDMA Reads and Atomic requests are not supported.

• Low traffic. Because the responder QP's RQ Logic doesn't Ack or Nak each request packet received, this service class generates considerably less network traffic than the “reliable” service types.

• Packet PSN checking. Just like the RC protocol, each request packet contains a PSN that the target QP's RQ Logic uses to verify that all request packets are received in order (and that each is only processed once even if it should be received multiple times). Unlike the RC protocol, however, if the responder QP's RQ Logic detects out-of-order request packets (i.e., one or more missing request packets), it is not permitted to send a Nak back to the requester QP's SQ Logic. If this should happen:

  - The responder QP's RQ Logic ignores the remaining request packets of the current message.

  - The responder QP's RQ Logic awaits the beginning of a new message (as signaled by a request packet with a BTH:Opcode of the “First” or “Only” type).

  - The responder QP's RQ Logic may (or may not) inform its local client (e.g., software) of the problem.

• Just like the RC protocol, two CRC fields in each packet are used to verify the integrity of the packet.

• Operations supported. Supports the following types of message transfer operations:

  - RDMA Write support is required.

  - Send support is required.

  - Bind Memory Window support is required.