Fab, you are correct. But this is DAPL issue not IBTA. As long IBTA defines support for current CM with full private data and enhanced semantic CM with reduced private data but socket addressing model support and OpenIB expose access to both of them the rest is DAPL issue. OpenIB will not have any backwards compatibility issue because this is the first version of DAPL they will support. But, of course, it will be nice if can support apps written to current version of DAPL.
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: Fab Tillier [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 20, 2005 1:34 PM > To: 'Michael Krause'; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [email protected] > Subject: RE: [openib-general] Re: [swg] Re: private data... > > > > From: Michael Krause [mailto:[EMAIL PROTECTED] > > Sent: Thursday, October 20, 2005 10:00 AM > > > > This is really an IBTA issue to resolve and to insure that backward > > compatibility with existing applications is maintained. > Hence, this > > exercise of who is broken or not is inherently flawed in that one > > cannot comprehend all implementations that may exist. > Therefore, the > > spec should use either a new version number or a reserved > bit to indicate that there is a defined format to > > the private data portion or not. This is no different > than what is done in > > other technologies such as PCIe. Those applications that > require the > > existing semantics will be confined to the existing associated > > infrastructure. Those that want the new IP semantics set the bit / > > version and operate within the restricted private data space > > available. It is that simple. > > While I agree with you, the issue at hand is that DAPL tries > to do both - providing IP semantics to the application *and* > 64-bytes of private data. While the IBTA may use a reserved > bit to differentiate native IB or IP-enhanced connection > establishment MADs, if DAPL is to use this feature then DAPL > clients will lose some of their private data. This gets us > back to how to handle DAPL clients that depend on the full 64 > bytes of private data and how to support them, which is a > DAPL issue IMO and not an IBTA issue. The IBTA should do > what's right for IB independently of DAPL, and define a > proper IP-enhanced CM protocol. > > - Fab > > > _______________________________________________ > 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
