[ofa-general] AF_INET_SDP value

[Gleb Natapov]

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: jim at mellanox.com
> Phone: 512-294-5481
> 
> From: Michael Krause [mailto:krause at cup.hp.com] 
> Sent: Monday, January 07, 2008 9:09 AM
> To: Jim Mott; Lenny Verkhovsky; general at lists.openfabrics.org
> 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: general-bounces at lists.openfabrics.org [ mailto:general-bounces at lists.openfabrics.org] On Behalf Of Lenny Verkhovsky
> Sent: Sunday, January 06, 2008 10:24 AM
> To: general at lists.openfabrics.org
> 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
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general 
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

--
			Gleb.