This is indeed how SDP works on Linux. The unmodified binary runs against the libsdp shared library and the right things happen.
The AF issue comes in because of a requirement (request, desire, misunderstanding, creeping feature?) to be able to create SDP only applications that can bypass the library and run directly against SDP. These applications, for example, will fail if the target system is not running SDP where the library approach silently falls back to TCP. While I am not sure of who the non-libsdp consumer of this AF is, I am sure that there is a non-technical problem just defining a new address family. The end result is that AF_INET_SDP is not defined in any normal OS place. Maybe this is correct behavior. I could certainly argue both sides. Thanks, JIm Jim Mott Mellanox Technologies Ltd. mail: [EMAIL PROTECTED] Phone: 512-294-5481 From: Michael Krause [mailto:[EMAIL PROTECTED] Sent: Monday, January 07, 2008 9:09 AM To: Jim Mott; Lenny Verkhovsky; [email protected] Subject: RE: [ofa-general] AF_INET_SDP value 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
