[openib-general] Re: [swg] Re: private data...

[Caitlin Bestler]

> -----Original Message-----
> From: openib-general-bounces at openib.org 
> [mailto:openib-general-bounces at openib.org] On Behalf Of Fab Tillier
> Sent: Thursday, October 20, 2005 11:20 AM
> To: 'Sean Hefty'
> Cc: swg at infinibandta.org; dat-discussions at yahoogroups.com; 
> openib-general at openib.org
> Subject: RE: [openib-general] Re: [swg] Re: private data...
> 
> > From: Sean Hefty [mailto:mshefty at ichips.intel.com]
> > Sent: Thursday, October 20, 2005 11:11 AM
> > 
> > Fab Tillier wrote:
> > > I would personally rather see a reserved bit get used.
> > > Imagine a system that has two protocols installed that use IP 
> > > addressing.  That system might want to have different 
> apps listening 
> > > on the same port number over both, even though the protocols are 
> > > different.
> > 
> > I don't think that this maps well to TCP.  Apps need to listen on 
> > different ports.
> 
> Are DAPL apps TCP apps?  I thought they just wanted to use IP 
> addresses for connection establishment, but weren't actual 
> TCP apps.  If DAPL apps aren't TCP apps, should they block 
> usage of the TCP port from real TCP apps?
> 
> > > Having a reserved bit in the REQ indicate the presence of IP 
> > > addressing information (including source and destination port
> > > numbers) in the private data seems most flexible to me.
> > 
> > How would a reserved bit help here?  How does the CM know 
> which app to 
> > give the request to?
> 
> Based on the ServiceID provided by the applications on both 
> sides of the connection.
> 

The closest thing that you come to having "two services" on one
TCP port would be iSER-style services. Full emulation of this
would require establishing an SDP connection, using SDP to exchange
messages to establish that the remote peer was RDMA capable, and
then "converting" the socket to RDMA mode (i.e., disabling the
SDP handling).

Using RDMA to simulate sending of streaming mode messages for
the purpose of determining whether the remote peer supports RDMA
is at the minimum rather strange.

The effort to benefit ratio on that one is far from convincing.
Supporting transport neutral connection setup for applications that
*know* they are using RDMA semantics is 90% of the benefit at way
less than 90% of the effort.

For what it's worth the SCTP adaptation of iWARP does *not* support
this TCP feature. So if an IP protocol doesn't think it is worth
emulating then why should IB do it?

The transport neutral approach is to say that the application determines
whether RDMA is supported. If it knows RDMA is supported it establishes
a connection to a TCP port that is advertised as supporting RDMA. If the
network in use is IB then there is no need to send a wire message to
establish that RDMA is supported.