frank zago wrote:
I was trying to match the existing MAD API. The CM would perform timeouts, but not retries. Consumers could retry request immediately upon notification of a timeout. This lets the client change the timeout value. (I'm negotiable on this, but the cost of having clients initiate retries is basically one function call.)
I have given some thought to how retries should work. I've thought about adding a new call, ib_retry_cm_send() - or something like that, that resends the last message sent. Or the callback could indicate to retry.
I have the same problem here than with the handler. A client should be able to set timeouts and retries, and let CM take care of the painful stuff.
The complexity should be in the CM, not repeated amongst the clients.
I am trying to avoid adding policy or hard-coding default values into the CM, and follow the same design decisions that we used with the current APIs. Long term I think simpler interfaces will be a better solution.
Areas where the majority of clients will need to implement the exact same code make sense to push into the CM. So far there doesn't seem to be any disagreement that the CM has features that it doesn't need. And the list of desired features seem to be:
* Perform QP transitions for the user. * Provide default values when establishing a connection. * Perform retransmissions. * Destroy connection identifiers from/after a callback.
Are there others?
- 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
