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