Or Gerlitz wrote: > 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
Side note: type 3 would be userspace CMA users. > 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? The behavior of this patch is the same in all three cases. For type 1, calling ib_cm_establish() along with transitioning the QP to RTS is sufficient. This method is also usable by type 2, if the CMA were to intercept the COMM_EST events. The method breaks down for type 3 because there's no way for the CMA to get the COMM_EST event. I would say that this provides a full solution for all types of consumers, and agree that ib_cm_establish() could be removed from the API. However, keeping it prevents breaking the ABI, and it does have limited use if called as a result of polling a receive completion, by forcing the connection into the established state immediately. - 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
