[openib-general] [RFC] IB address translation using ARP

[Caitlin Bestler]

> -----Original Message-----
> From: openib-general-bounces at openib.org 
> [mailto:openib-general-bounces at openib.org] On Behalf Of 
> Christoph Hellwig
> Sent: Friday, October 14, 2005 2:26 AM
> To: Michael Krause
> Cc: openib-general at openib.org
> Subject: Re: [openib-general] [RFC] IB address translation using ARP
> 
> On Thu, Oct 13, 2005 at 10:29:09AM -0700, Michael Krause wrote:
> > This all comes down to economics which is why some ULP such 
> > as SDP are created.  Let's examine SDP for a moment.  The purpose
> > of SDP to enable synchronous and asynchronous Sockets applications to 
> > transparently run unmodified over a RDMA capable interconnect.
> > Unmodified means no source code changes and no recompile required
> > (this is possible if the Sockets library is a shared library and
> > dynamically linked).   The first part of unmodified means that the
> > existing address / service resolution API calls work (further, no
> > change to the address family, etc. is required to make this work either).
> > Hence, pick any of the get* API calls that 
> > are in use today and they should just work.
> 
> That's not who SDP is going to work on Linux, though.  Where 
> not into your crude hacks to let broken applications work 
> with new technology business.  Applications will have to use 
> SDP directly or via getaddrinfo and we will never put in a 
> broken sockets switch.
> 

I can't think of a better example of something that is truly
brain dead than an application *written* to use Sockets Direct
Protocol.

The protocol offers *zero* advantages to the network or to
the application over direct use of RDMA (or of TOE) unless
you presume that the application will continue to use a
sockets API. If the application is using a QP/CQ API it
does not need, and should not use SDP.

The sole technical merit of SDP is its ability to support
streaming semantics that very precisely match the current
semantics for sockets over TCP without requiring byte stream
support in the hardware. It has poorer network utilization
compared to TOE, and every objection raised to TOE applies
to SDP. So if you aren't preserving the sockets API what is
the point in using the protocol?

> And can you _please_ stop all thise time to market and 
> similar business crap?  That simply doesn't matter when 
> designing something properly.

If we really were to play stop-the-world-while-I-redesign-it
games then the resulting solution would not use sockets, TCP
or even Linux. Real solutions, from NICs through Operating
Systems, recognize that their legacy is part of their strength
as well as a nuisance.