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. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general