[Rdma-developers] Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

[Christoph Hellwig]

On Tue, May 31, 2005 at 02:03:06PM -0700, Tom Duffy wrote:
> On Sat, 2005-05-28 at 09:13 +0200, Christoph Hellwig wrote:
> > On Fri, May 27, 2005 at 03:56:58PM -0700, Bob Woodruff wrote:
> > > kDAPL is intended as a kernel-level API
> > > for RDMA enabled fabrics. As it was initially written,
> > > it does not meet the Linux coding style and that is why
> > > it is being totally reworked as we speak to meet that goal. 
> > 
> > The codingstyle alone isn't the problem.  The whole design philosophy
> > is rather odd.
> 
> As one of the people trying to clean up kDAPL, I would like to know what
> you think, from a design philosophy, is wrong with it.  We *can* correct
> any daim bramaged parts.

kDAPL is supposed to serve two needs:

 (1) provide an unified API for different RDMA transports
 (2) provide various higher level helpers

as such it's largely duplicating what a proper RDMA stack should be.

For (1) doing a proper RDMA stack should solve thing, and the discussion
how to do it is already ongoing on this list.  Once we have proper RMDA
stack that part of KDAPL isn't needed at all anymore.  The second is
more interesting and there's indeed the need for some higher level
helpers than the API at the level of the current OpenIB code offers. But
having a separate layer, with different data structures, provider
registration and a totally different API for that is utter nonsense.
Instead the higher level helpers should operate on the same
datastructures as the RDMA stack, or build new ones ontop of that.
In addition some of the abstractions don't make much sense, the event
handling has already been mentioned.