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

[Caitlin Bestler]

Sean Hefty wrote:
> Tom Tucker wrote:

> 
>> +		cm_id_priv->id.state = IW_CM_STATE_ESTABLISHED;
>> +	} else
>> +		cm_id_priv->id.state = IW_CM_STATE_IDLE;
>> +
>> +	spin_unlock_irqrestore(&cm_id_priv->lock, flags); +
>> +	/* Call the client CM handler */
>> +	return cm_id_priv->id.cm_handler(&cm_id_priv->id, &work->event);
}
>> + +/*
>> + * CM_ID <-- CLOSING
>> + *
>> + * If in the ESTABLISHED state, move to closing and disassociate the
>> + * CM_ID from the QP. The provider will have already moved the QP to
>> + * CLOSING.
> 
> It's confusing trying to figure out who's responsible for QP
> transitions.  In some places, the iw_cm performs the
> transitions.  In others, the provider is expected to have
> performed them.  Is there a way to make this consistent, so
> that all QP transitions are initiated from the same location?
>  It seems that we're open to bugs if different modules drive
> the QP state without strict coordination between them.
> 

A clean state diagram or table should provide that without
forcing all transitions to be originated at one point.

In particular, transitions that are triggered by errors
or packets seen by the Provider SHOULD be acted upon promptly.
For example, the Provider really SHOULD NOT send a new message
if it has been told by its peer to disconnect. That might even
be a MUST NOT. The Provider can only guarantee that if *it*
makes that change to the QP state. Sending a new request on
a TCP stream *after* acking the Disconnect is problematic.

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.