[openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

[Roland Dreier]

I believe the way forward is to evolve the existing drivers/infiniband
code already in Linux into a drivers/rdma that supports both IB and
RNICs.  To be extremely blunt, I believe the RNIC-PI is irrelevant to
the Linux kernel -- no IB vendors will support ripping out a working
midlayer and starting from scratch, and it doesn't make sense to have
two essentially equivalent midlayers in the same kernel.

To put a really concrete proposal on the table, I would suggest to
start by extending the current ib_client registration structure, which
looks like

	struct ib_client {
		char  *name;
		void (*add)   (struct ib_device *);
		void (*remove)(struct ib_device *);
	
		struct list_head list;
	};

by extending the current enum ib_node_type to something like

	enum rdma_device_type {
		RDMA_DEVICE_IB_CA,
		RDMA_DEVICE_IB_SWITCH,
		RDMA_DEVICE_IB_ROUTER,
		RDMA_DEVICE_RNIC
	};

Then the various pieces of code layered on top of the RDMA midlayer
can decide whether they want to deal with a particular device or not
by looking at the node_type member.  For example, the IB CM, IPoIB,
etc. could ignore devices of type RDMA_DEVICE_RNIC, while SDP or iSER
would use all devices and the RNIC CM would take only devices of type
RDMA_DEVICE_RNIC.

Then someone would have to start implementing a low-level driver for a
specific RNIC, and find which modifications to the existing verbs are
required.  For example, I believe the QP attribute structure passed
into the QP modify verb probably has to become a union containing the
IB attributes and the RNIC attributes.  However, most verbs should
work fine with at most trivial modifications.

The existing OpenIB SDP code will be a good example to study as we
determine what abstractions need to be added to make it simple for
consumers to deal with the differences between IB and RNIC.

 - R.