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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
