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
