On Fri, Jan 21, 2005 at 11:37:55AM -0800, Sean Hefty wrote: > Libor Michalek wrote: > > 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. > > That makes sense. I was concerned about the CM saving the event > information for an arbitrary time, but hadn't looked at what was needed > between callbacks. > > Would it be acceptable to only support those calls during the > connection establishment phase, which would allow the CM to free the > event information? (Not sure what that does to path migration.)
I think it would be OK to free it after connection establishment, on the flip side, I don't think that it's so much data that holding it for the life of the connection would be a problem either. In our experience we held onto this data for the life of the connection, and were still able to manage 10's of thousands of connections. Either way, once it is there, this would be something that's easy to change in the future. -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
