[Rdma-developers] RE: [openib-general] OpenIB and OpenRDMA: Convergence on commonRDMA APIs and ULPs for Linux

[Caitlin Bestler]

> -----Original Message-----
> From: rdma-developers-admin at lists.sourceforge.net 
> [mailto:rdma-developers-admin at lists.sourceforge.net] On 
> Behalf Of Sean Hefty
> Sent: Friday, May 27, 2005 9:22 AM
> To: 'Roland Dreier'; Venkata Jagana
> Cc: rdma-developers at lists.sourceforge.net; openib-general at openib.org
> Subject: [Rdma-developers] RE: [openib-general] OpenIB and 
> OpenRDMA: Convergence on commonRDMA APIs and ULPs for Linux
> 
> >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.
> 
> Is there some technical reason why this proposal cannot be 
> used?  I didn't notice any other proposal.
> 
> - Sean
> 

There isn't enough there to go farther.

What methods is the RDMA_DEVICE_RNIC required to support?

a) Totally iWARP specific methods. That works, but all you've done
   is taken two stacks and put a switch on top of them. kDAPL already
   does that quite well.
b) The same methods, but with different struct and enum definitions?
   (i.e., a struct iwarp_qp versus a struct ib_qp). IMHO, that doesn't
   differ much from a)
c) The same methods but with struct/enums that have common and transport
   specific portions? That is doable, in fact that is what RNIC-PI is
   today. Repeating that work with the gen2 verbs will be time
consuming.
   I don't want to have to wait 4 months to debate the details of this
   before I can start working on my next generation of verbs.
d) Use the methods and structs 'as is' and just somehow figure out how
   they map to iWARP? That is no more "transport neutral" than Tom DeLay
   is "bipartisan".