The value of AF_INET_SDP is defined in the shipped file sdp_socket.h. It is used by the kernel module build, the libsdp build, and applications that decide to explicitly use SDP.
Since we build the module and libsdp on the target system, things will work. The problem is that the value selected for AF_INET_SDP might someday conflict with a real standard address family definition. When this happens, something (SDP or a standard AF) will be broken. JIm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gleb Natapov Sent: Tuesday, January 08, 2008 5:59 AM To: Jim Mott Cc: Lenny Verkhovsky; [email protected] Subject: Re: [ofa-general] AF_INET_SDP value On Mon, Jan 07, 2008 at 01:36:09PM -0800, Jim Mott wrote: > This is indeed how SDP works on Linux. The unmodified binary runs against > the libsdp shared library and the right things happen. libsdp opens AF_INET_SDP socket. If the value of AF_INET_SDP is not standard libsdp may work on some OSes and not on others. > > 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 -- Gleb. _______________________________________________ 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
