[ewg] Announce: OFED-RDMAoE-1.5 rc1 is available

[Eli Cohen]

Abstract
--------

RDMA over Ethernet (RDMAoE) allows running the IB transport protocol using
Ethernet frames, enabling the deployment of IB semantics on lossless Ethernet
fabrics. RDMAoE packets are standard Ethernet frames with an IEEE assigned
Ethertype, a GRH, unmodified IB transport headers and payload.  IB subnet
management and SA services are not required for RDMAoE operation; Ethernet
management practices are used instead. RDMAoE encodes IP addresses into its
GIDs and resolves MAC addresses using the host IP stack. For multicast GIDs,
standard IP to MAC mappings apply.

To support RDMAoE, a new transport protocol was added to the IB core. An RDMA
device can have ports with different transports, which are identified by a port
transport attribute.  The RDMA Verbs API is syntactically unmodified. When
referring to RDMAoE ports, Address handles are required to contain GIDs while
LID fields are ignored. The Ethernet L2 information is subsequently obtained by
the vendor-specific driver (both in kernel- and user-space) while modifying QPs
to RTR and creating address handles.  As there is no SA in RDMAoE, the CMA code
is modified to fill the necessary path record attributes locally before sending
CM packets. Similarly, the CMA provides to the user the required address handle
attributes when processing SIDR requests and joining multicast groups.

In this version, an RDMAoE port is currently assigned a single GID, encoding
the IPv6 link-local address of the corresponding netdev; the CMA RDMAoE code
temporarily uses IPv6 link-local addresses as GIDs instead of the IP address
provided by the user, thereby supporting any IP address.

To enable RDMAoE with the mlx4 driver stack, both the mlx4_en and mlx4_ib
drivers must be loaded, and the netdevice for the corresponding RDMAoE port
must be running. Individual ports of a multi port HCA can be independently
configured as Ethernet (with support for RDMAoE) or IB, as is already the case.
We have successfully tested MPI, SDP, RDS, and native Verbs applications over
RDMAoE.

API changes
-----------
There are no API changes to the verbs interface in order to use RDMAoE.
However, applications are required to set up the QPs they use such that they
will use GRH. For this they need to supply the remote host's GID. For connected
QPs, this needs to be done when modifying the QP from INIT to RTR. For UD QPs
this has to be done when creating the UD address vector.

struct ibv_port_attr has been extended and now it contains a new field named
transport which is used to return the transport type of the corresponding port;
it can have the values RDMA_TRANSPORT_IB, RDMA_TRANSPORT_IWARP or
RDMA_TRANSPORT_RDMAOE. Applications can use this in order to take actions as
for whether GRH is a must or not.


Userspace applications
----------------------

The following applications have been adapted:

ibv_devinfo - now it show the link type.
ibv_rc_pingpong
ibv_ud_pingpong
ib_uc_pingpong
ibv_srq_pingpong
ib_write_lat