Just to add there is a Lustre NAL over kDAPL in development And few other application specific protocols done over kDAPL I know of All those protocols Arkady mentioned can work on both RDMA technologies and where designed in such a way (I'm familiar with their code and architecture).
And another grate benefit of kDAPL is the simplification of the Verbs & Access Layer API, making the ULP's simpler to implement, where a lot of common functionality is done by a shared library (kDAPL) And with a socket like connection establishment flow, etc' If we want IB to be successful we need to find a way for software developers to easily build implementations over it (even if not all of the Applications are open and part of the Linux tree), forcing all Linux RDMA developers to code to Verbs, CM, SA, ... is probably not the best approach (the IB spec is many pages as you all know). For all the guys worried about performance degradation, the latest Verbs vs DAPL benchmark we did we got 100% the same BW and ONLY 200ns latency difference. There is agreement that the current kDAPL API and implementation are not Linux friendly, and as mentioned before a bunch or people volunteered at Sonoma to do the work involved in changing it, and agree to make kDAPL API different than uDAPL and more suitable for kernel. Yaron > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:openib-general- > [EMAIL PROTECTED] On Behalf Of Kanevsky, Arkady > Sent: Friday, February 11, 2005 1:49 AM > To: Libor Michalek; Matt Leininger > Cc: Christoph Hellwig; [email protected]; Tom Duffy > Subject: RE: FW: [openib-general] Minutes from DAPL BOF at OpenIB Workshop > > For kDAPL: > The iSER has been submitted to Open Ib by Voltaire already. > NFS-RDMA is at http://sourceforge.net/projects/nfs-rdma/. > > For uDAPL: Oracle, DB2 and MPI. > I am not aware if there is an open source MPI version on uDAPL. > > These are publicly known. > > As far as changing the uDAPL or kDAPL APIs. > There are application already writen to them. > There are implementation of these APIs on other platforms besides Linux. > It is in nobody's interest to splinter the user community. > We need the same API on all platforms. > If there is a good technical reason to change some specific APIs we > should consider it. > But the "burn the spec" approach is not a rationale one. > If we need to change implementation or some definitions in header files > it is feasible. > > As far as other transport. As people already mentioned iWARP (IETF > RDDP). > IBM talked at the BOF about RNIC PI which is being developed as a level > of > abstraction on the lower end to "discover" all the need info about > RNIC/HCA. > It is still no ready so we will start with gen2. > But lets not loose site of what DAPL brings: > OS independent, > Transport independent, > RDMA APIs!!! > > Thanks for jumping on the code so quickly. > Arkady > Chair of DAT Collaborative > > Arkady Kanevsky email: [EMAIL PROTECTED] > Network Appliance phone: 781-768-5395 > 375 Totten Pond Rd. Fax: 781-895-1195 > Waltham, MA 02451-2010 central phone: 781-768-5300 > > > > > -----Original Message----- > > From: Libor Michalek [mailto:[EMAIL PROTECTED] > > Sent: Thursday, February 10, 2005 4:03 PM > > To: Matt Leininger > > Cc: Christoph Hellwig; [email protected]; Tom Duffy > > Subject: Re: FW: [openib-general] Minutes from DAPL BOF at > > OpenIB Workshop > > > > > > On Thu, Feb 10, 2005 at 12:36:39PM -0800, Matt Leininger wrote: > > > On Thu, 2005-02-10 at 12:27 -0800, Grant Grundler wrote: > > > > On Thu, Feb 10, 2005 at 12:05:58PM -0800, Matt Leininger wrote: > > > > > uDAPL - Oracle, MPI > > > > > kDAPL - iSER, NFS over RDMA, Lustre? > > > > > > > > Lustre will use Sandia Portals AFAIK. > > > > Anyone know what Portals will use? > > > > They might directly program to VAPI or something. > > > > > > > There will be a Portals over verbs. At some point there may be a > > > Portals over kDAPL to support both RDMA ethernet and IB. > > > > Yup, that's one of the bigger questions, can it abstract > > away the differences between two different RDMA technologies? > > Having a RDMA ethernet and IB providers for kDAPL is > > insufficient, one would need to show an actual, non-trivial, > > protocol that works ontop of either provider with no, or > > little, modification/ifdef'ing. > > > > -Libor > > > > > > _______________________________________________ > > openib-general mailing list > > [email protected] > > http://openib.org/mailman/listinfo/openib-> general > > > > To > > unsubscribe, please visit > > http://openib.org/mailman/listinfo/openib-general > > > _______________________________________________ > openib-general mailing list > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib- > general _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
