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