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

[Bob Woodruff]

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. 

James/Arkady 

Comments ?

woody