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

[James Lentini]

On Fri, 27 May 2005, Bob Woodruff wrote:

> Caitlin wrote,
>> Both uDAPL and kDAPL were designed for *application* use.
>> Even kDAPL is more intended for use by a kernel daemon that
>> is loaded separately from the kernel than for use within
>> the kernel itself.
>
> 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.
>
>> An ideal API for use within the kernel would abstract as
>> much as possible (without requiring emulation), and then
>> have transport specific unions or enum values. It would
>> hide no control options, merely provide common controls
>> for common capabilities.
>
> So for every new RDMA device type that comes along, you need to add a new
> enum, and unions for device class specific stuff, etc.
> Seems rather static and not easily extended. Not
> to mention that testing nightmare when the thing has to support
> 20 different types of RDMA enabled devices.
> I think code like that could get pretty ugly pretty fast.
>
> I'd rather see a registration mechanism like what we already have
> with DAPL that does not require any code changes to add a new RDMA
> device/provider.  We have already proven that this works in DAPL
> as I know if at least 3 providers, IB, Myrinet, and RNIC (Ammasso)
> that were developed separately and were able to co-exist without
> any changes (enums and device class unions) in the DAT mid-layer.
> I assume that this can also be done with kDAPL in the kernel, but
> I defer to the DAPL experts to answer that one.

Correct. The DAT API (kernel and user) is designed to support 
heterogeneous providers. The modifications we are making in

https://openib.org/svn/gen2/users/jlentini/

will not change that.

james