Sean Hefty wrote: >> +/** >> + * ib_cm_establish - Forces a connection state to established. >> + * @cm_id: Connection identifier to transition to established. >> + * >> + * This routine should be invoked by users who receive messages on a >> + * connected QP before an RTU has been received. >> + */ >> +int ib_cm_establish(struct ib_cm_id *cm_id); >> >> As with your patch ib_cm_establish is now called internally from within >> the CM with the suggested solution good for both user and kernel space >> connections/qps, how about removing it from the API? > > I thought about removing it, but it changes the ABI, and existing users may > still want to call ib_cm_establish() after processing a receive completion. > This will let them immediately send a response without waiting for either the > RTU or the COMM_EST event.
there are three types of CM/VERBS consumers: 1) work over the CM/VERBS 2) work over the CMA/VERBS with the CMA doing the QP state changes 3) work over the CMA/VERBS with the ULP doing the QP state changes Your patch provides ***full*** solution for type 2 consumers. Type 3 consumers can't call ib_cm_establish since they don't interact with the CM, as for type 1 consumers, looking on the CM code i was not able to convince myself that calling ib_cm_establish along with modifying the qp state to RTS would provide a full solution for them, what do you think? Or. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
