frank zago wrote:
+int ib_send_cm_req(struct ib_cm_id *cm_id, + struct ib_cm_req_param *param); +
The Topspin API: int ib_cm_connect(struct ib_cm_active_param *param, struct ib_path_record *primary_path, struct ib_path_record *alternate_path, tTS_IB_SERVICE_ID service_id, int peer_to_peer, ib_cm_callback_func function, void *arg, tTS_IB_CM_COMM_ID *comm_id)
Main difference here is that the parameters have been folded into one. (I'm not sure why ib_cm_active_param didn't just include the others.)
+int ib_send_cm_rep(struct ib_cm_id *cm_id, + struct ib_cm_req_param *param);
int ib_cm_accept(tTS_IB_CM_COMM_ID comm_id, struct ib_cm_passive_param *param)
Nearly identical. Missing field was added to ib_cm_req_param that was lacking in ib_cm_passive_param.
+int ib_send_cm_rtu(struct ib_cm_id *cm_id, + void *private_data, + u8 private_data_len);
int ib_cm_confirm(tTS_IB_CM_COMM_ID comm_id, void *rtu_private_data, int rtu_private_data_len)
Same.
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.
As pointed out above, this interface is similar to Topspin's.
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 API does use a callback model based on events. You register for a callback by calling ib_create_cm_id.
- 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
