[openib-general] [PATCH] initial CM module
Libor Michalek
libor at topspin.com
Thu Dec 16 14:37:58 PST 2004
On Thu, Dec 16, 2004 at 04:10:52PM -0600, frank zago wrote:
>
> I've used several CM and I found this kind of interface to be painful to
> use.
> I'd rather see an interface similar to Topspin's where you register a CM
> callback, get CM events and react (or not) to these.
>
> With the interface you propose it takes maybe 200 lines of code to
> establish a simple connection, while with a callback it can be down to
> 30 lines. It should be as easy as possible for an application or a
> driver to establish a connection. I shouldn't have to rewrite a CM state
> machine every time I need a connection.
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:
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.)
For this to work the corresponsing consumer callback needs to have
return parameters to retrieve the parameters to generate the next
CM response. So the callback consumer must set the return parameters if
it uses the success return value.
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.
-Libor
More information about the general
mailing list