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

[Caitlin Bestler]

> > 
> > Are DAPL apps TCP apps?  
> 
> DAPL doesn't mandate any particular network transport. 
> However the API uses sockaddrs to hold network addresses. The 
> specification says that these should contain IP addresses.
> 
> > 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?
> 
> They should not.
> 

DAPL defines two connection models.

One is presumed to be transport neutral and assumes RDMA
capability. There is one exchange of private data to enable
configuring RDMA properly. This is the original mapping, and
what should have priority in Connection Management discussions.
It is the only mode currently proposed for iWARP support because
the other modes bring up more stack integration issues.

There is a second mode where a SOCK_STREAM handle can be used
to exchange streaming mode messages (with TCP semantics) and then
either continuing in streaming mode or conveting ot RDMA mode.
That one is not worth handling in a transport neutral manner.

When the transport neutral model is mapped to iWARP the TCP
port is indeed pre-empted. But that does not mean that the
InfiniBand mapping must do the same. The only thing that needs
to be guaranteed is that a DAPL client (or any RDMA client that
assumes RDMA mode) will be able to request a connection without
risk that the connection request will be answered by a streaming
mode server. iWARP solves that with the MPA Request/Response
exchange. But transport neutral applications do not need to know
what mechanism is used to prevent streaming/RDMA mode mismatches.
There is also no need to guarantee that there is no streaming
mode service using the same conceptual TCP port number, but it
is one way to ensure that the connection requests cannot be
misdirected.