Technically, there was never a solid technical reason to require a new AF_INET_SDP value since SDP should be transparently interposed underneath a Sockets AF_INET application (the SDP port mapper protocol helps in this regard as well). The intended reason for SDP in the first place is to enable Sockets-based applications to transparently, i.e. non-modified source and if using shared libraries, non-modified binaries, to take advantage of RDMA interconnects. This is how it is implemented on Windows and other OS that support SDP or in Window's case, the prior incarnation called Winsocks Direct.
While making a modification to the address family may seem trivial to most, the simple act of opening up the application source to any change is a major issue to many enterprise customers. Given SDP adoption is nascent and there are competing approaches to protocol acceleration technology coming to market or being explored as well as a lot of unfortunate marketing FUD, the developers might want to think about what it would take to support SDP as originally intended by the IBTA and IETF.
Mike
At 10:21 AM 1/6/2008, Jim Mott wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C85090.FC407BBA"
I do not believe so. There are some politics involved. This value is shipped as part of the user space libsdp code. Perhaps someone that knows more history on this can comment?
From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]] On Behalf Of Lenny Verkhovsky
Sent: Sunday, January 06, 2008 10:24 AM
To: [email protected]
Subject: [ofa-general] AF_INET_SDP value
Hi,
Is AF_INET_SDP equals 27 is standartized for all architectures and kernels ?
Best Regards,
Lenny.
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
_______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
