Libor Michalek wrote:
This ties into what I was saying about an error return value from the consumer callback being treated as a connection handle destroy request. There were three return types supported:
I'm not opposed to this. I just haven't thought about it enough.
error - connection handle destroy request defer - CM requires an API call to continue. (e.g. REQ callback requires a send_rep() call to continue) What the Sean's API does by default. success - CM generates callback response. (e.g. REQ callback completed successfully so the CM generates a REP response.)
However, I'm not sure that not having this ability is that big of a code bloat, since you will call the corresponsing API function from the callback, and presumably set similar parameters for the API call as you would set for the callback return parameters. The bigger increase in consumer line count is having each consumer perform the QP state transitions.
I agree. I'm not sure that success is needed. This adds several parameters that need to be returned from the callback to save a single function call.
- 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
