Open Fabrics Enterprise Distribution (OFED)
             RDS in OFED 1.3 Release Notes
			  
			   February 2008


===============================================================================
Table of Contents
===============================================================================
1. Overview
2. Supported Platforms
3. Installation & Configuration
4. New Features
5. Bug fixes and Enhancements since OFED 1.2 

===============================================================================
1. Overview
===============================================================================
RDS socket API.  It provides reliable, in-order datagram delivery between 
sockets over a variety of transports.
For details see RDS.README.txt and man 7 rds.
Also available at: http://oss.oracle.com/projects/rds/dist/documentation/rds.7.txt

===============================================================================
2. supported platforms
===============================================================================

        RHEL4.0 Update 3,4,5
        RHEL5.0
        SLES 10

===============================================================================
3. Installation & Configuration
===============================================================================
To install RDS select rds in OFED's manual installation or put 'rds=y' in the
ofed.conf for unattended installation.

To load RDS module upon boot edit file '/etc/infiniband/openib.conf' as 
follows:

# Load RDS module
RDS_LOAD=yes

===============================================================================
4. New Features
===============================================================================

RDS V3 adds support for RDMA opertions. 

The principal mode of operation for RDS zerocopy is like this: 

One participant (the client) wishes to initiate a 
direct transfer to or from some area of memory in its process address space.
This memory does not have to be aligned.

The client obtains a handle for this region of memory, and
passes it to the other participant (the server). This is called
the RDMA cookie.

The client sends this handle to the server application, along with other 
details of the RDMA request (such as which data to transfer to that memory area).
Throughout the following discussion, we will refer to this
message as the RDMA request.

The server uses this RDMA cookie to initiate the requested RDMA
transfer. The RDMA transfer is combined atomically with a
normal RDS message, which is delivered to the client. This
message is called the RDMA ACK throughout the following.  Atomic
in this context means that if the RDMA ACK succeeds, then the RDMA 
has completed. If the RDMA ACK is not delivered, the client can not 
assume anything about the success of the RDMA.

Thus, when the client receives the RDMA ACK, it knows that
the RDMA has completed successfully. It can then release the
RDMA cookie for this memory region, if it wishes to.

See man 7 rds for more details. 

===============================================================================
5. Bug fixes and Enhancements since OFED 1.2 
===============================================================================

1) Wire protocol for RDS v3 and RDS v2 are not compatible. 

2) RDS over TCP is disabled in OFED 1.3. We will re-enable in future release.

3) Congestion monitoring support gives the application more fine-grained control.

With explicit monitoring, the application polls for POLLIN as before, and 
additionally uses the RDS_CONG_MONITOR socket option to install a 64bit mask 
value in the socket, where each bit corresponds to a group of ports. 
When a congestion update arrives, RDS checks the set of ports that became 
uncongested against the bit mask installed in the socket. If they overlap, a 
control messages is enqueued on the socket, and the application is woken up. 
When application calls recvmsg (2), it will be given the control message 
containing the bitmap on the socket.