[openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3

[Sean Hefty]

Kanevsky, Arkady wrote:
> Which entity is responsible to "use" the proposed protocol is an
> interesting one.
> I was assuming that this will be CM. After all the proposed protocol is
> CM extension
> protocol.
> But it can be another entity module between CM and ULP.

The use of a reserved bit in the CM message indicates that the CM itself needs 
to set this data.  This requires communication between the CM and IPoIB - in 
essence making IPoIB part of the CM.  Removal of the reserved bit is what 
permits another entity between the CM and the ULP to perform this task.

> While it is possible to do wildcarding on the whole SID, I had not seen
> it is used selectively on individual bits of a SID or a port.

This is what is done/needed to support SDP.  A simple mask is applied to the SID 
  before comparing against a local listen.

> While SDP does the conversion to IB SID from Ethernet port, this
> proposal
> shift the responsibility for port and IP address conversion from ULP
> down.

Ideally, SDP should use this same mechanism, but requires changes to SDP.

> Protocol version. This mean that in the future if protocol version will
> be
> bumped up we will have to change the SID on which Consumer listens on
> and
> requests sent to. Not sure how to do that without changing ULP. Does not
> look
> like a good idea.

As a note, I'm not saying that I prefer a more complex SID, just that there is 
trade-off to be made that could provide for more ULP private data.

If the version changes, then the addressing has changed.  The ULP may need to 
change anyway in order to know how to interpret the address.  If they don't care 
about the protocol version or don't need to know how to interpret the address, 
they can still wildcard the version.

> IP version. This can be incorporated into SID. But if HCA has multiple
> IP addresses
> assigned to it the listening point need to specify its IP address(es).
> The current verbs and/or API will have to be changed to support it.
> But if socket is passed to listen on it does have all the needed info.
> Looks fine.

I didn't follow this.

> DAPL APIs (uDAPL and kDAPL) does not expose local IP address for listen
> point.
> An additional API can be added to support passing local socket to listen
> on
> instead of Connection Qualifier. Since it is addition no backwards
> compatibility issues.
> The current ULPs/Apps will still use "the default API address" and the
> protocol assigned SID as connection qualifier.

The issue with DAPL is that it assumes that addressing has been resolved to a 
specific device before communication between the client and server have even 
occurred.  I.e. the server must be clairvoyant and know which device a 
connection request will be received on.  Likewise, a client must assume which 
local device is needed to connect to a given remote address.

- Sean