[openib-general] Re: [PATCH 3/3] iWARP CM

[Steve Wise]

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?