On Thu, 2006-03-16 at 13:16 -0800, Sean Hefty wrote: > >The bottom line requirement is that state transitions are > >atomic. As long as you know that at most one entity transitions > >the QP out of the Established state everything should work. > > I'll buy this. My comments and questions are just trying to make sure that I > understand everything that's happening, especially in areas where there's the > potential for a bug, more than there's a real issue. For example, is there > any > potential that the state could be driven two directions, with the resulting > state unknown? >
By 'unknown', do you mean the IWCM thinks the QP state is X and it really isn't? The provider must enforce proper state transition rules based on the RDMAC spec so that the QP only transitions according to the state machine. And the IWCM must handle qp_modify failures in case a transition attempt fails. There certainly are places where the CM can attempt to move the QP into some state, and that results in a synchronous error returned from modify_qp because the QP was already transitioned by the provider into some other state (namely ERROR). EG: The IWCM tries to move the QP to CLOSING to begin a normal close, but concurrently the provider moves the QP to ERROR because the TCP connection was dropped some reason. If the provider got there first, and moved the QP to ERROR, but the IWCM hasn't processed that CLOSE event yet, then the transition to CLOSING by the IWCM will fail. And the IWCM should handle this. (i hope it does ;-) Does this make sense? _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
