On Fri, Jan 21, 2005 at 11:10:30AM -0800, Sean Hefty wrote: > Libor Michalek wrote: > >>> int ib_cm_prep_rtr(struct ib_cm_id *, struct ib_qp_attr *); > >>> int ib_cm_prep_rts(struct ib_cm_id *, struct ib_qp_attr *); > >> > >>I just had a conversation this morning with someone about this exact > >>same functionality. I think that it makes sense to add these routines. > >>(The exact format/parameters for the API may need to be slightly > >>different.) > > > > What format were you thinking for the API? > > I haven't given the actual API/implementation much thought to say what > it would look like. What did occur to me was that the the struct > ib_cm_event might be needed. My plan is to implement this as soon as I > resolve the callback issue, since I could use it for testing.
The first part of what I suggested, was saving the event information needed for the QP state transitions in the communication identifier. The reason is that all the CM consumers are going to need to save this info, since the QP tansitions occur after the callbacks are complete. For example RTR->RTS on the passive side occurs after RTU is received, but some of the info that's needed is delivered in the original REQ. I was suggesting that the communication identifier should hold this info, otherwise each consumer will need to duplicate the storage. Once the cm_id is holding this data, the convenience functions are a natural extension. -Libor _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
