Hal Rosenstock wrote:
Would UC as well as RC be supported ? If so, UC can wait a little for
implementing if this adds time.
I'm not sure that RC or UC matters much to the CM. The CM will probably just read the value from the QP type.
/**
* ib_send_cm_mra - Sends a message receipt acknowledgement to a connection
* message.
* @cm_id: Connection identifier associated with the connection message.
* @service_timeout: The maximum time required for the sender to reply to
* to the connection message.
* @private_data: Optional user-defined private data sent with the
* message receipt acknowledgement.
* @private_data_len: Size of the private data buffer, in bytes.
*/
Couldn't outgoing MRAs be automatically generated rather than forcing the CM client to do this ?
I'm not sure that there's much value in abstracting this call. Also, there would need to be a way for the client to specify the private data and service timeout, which could change per message.
Would the CM be 1.1 compliant ? If so, would 1.2 be a future thing ?
I was looking at the 1.2 version of the spec, but was planning on pulling code from the existing Topspin CM. I'm guessing that it's 1.1 compliant. Depending on the differences between 1.1 and 1.2, I can try to support both.
struct ib_path_record; //*** TBD: define me somewhere else (ib_smi.h?)
Is this the SA PathRecord ? There is ib_sa_path_rec in ib_sa.h.
Thanks - I included ib_sa.h from ib_cm.h.
One final note, I'm hoping that a more abstracted CM could be layered on top of this one, if it were desired. E.g. one that performs QP transitions, automatically generates MRAs, retries requests, etc.
- 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
