[openib-general] Re: [swg] Re: private data...
Arkady.Kanevsky at netapp.com
Thu Oct 20 10:50:20 PDT 2005
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
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: arkady at netapp.com
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:ftillier at silverstorm.com]
> Sent: Thursday, October 20, 2005 1:34 PM
> To: 'Michael Krause'; dat-discussions at yahoogroups.com
> Cc: swg at infinibandta.org; openib-general at openib.org
> Subject: RE: [openib-general] Re: [swg] Re: private data...
> > From: Michael Krause [mailto:krause at cup.hp.com]
> > 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
> openib-general at openib.org
> To unsubscribe, please visit
More information about the general