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

Caitlin Bestler caitlinb at siliquent.com
Fri May 27 10:13:23 PDT 2005


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.

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.

It would also not bother to unify the event streams, but
rahter present the raw event streams. Applications find
that unification useful and enabling, but that is why
application APIs like uDAPL, kDAPL and IT-API exist.

Having the lowest level API possible within the kernel
is certainly a good long term goal, but as outlined elsewhere
I am skeptical that is achievable in the short term. kDAPL
would certainly provide an acceptable fill-in until such
an API could be ironed out.
 

> -----Original Message-----
> From: rdma-developers-admin at lists.sourceforge.net 
> [mailto:rdma-developers-admin at lists.sourceforge.net] On 
> Behalf Of Roland Dreier
> Sent: Thursday, May 26, 2005 9:33 AM
> To: Bob Woodruff
> Cc: 'Venkata Jagana'; rdma-developers at lists.sourceforge.net; 
> openib-general at openib.org
> Subject: [Rdma-developers] Re: [openib-general] OpenIB and 
> OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux
> 
>     Bob> There is already a RDMA device independent API being
>     Bob> developed for the kernel by people on this list. It is
>     Bob> starting with the kDAPL code base, which was designed to
>     Bob> support both IBA and iWarp devices.
> 
> I believe kDAPL-based layers are an OK short-term solution, 
> but I don't think anything like this should be proposed for 
> merging in the Linus kernel.  If we need another abstraction 
> layer on top of our existing abstraction layer, that just 
> says to me that we should fix the current abstraction layer.
> 
>  - R.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into 
> your own Applications - visit 
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Rdma-developers mailing list
> Rdma-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rdma-developers
> 



More information about the general mailing list