[ofw] IBAL CEP reference counting is... interesting

[Sean Hefty]

>Ok, fine, it's a reference to trigger invoking the destroy callback when all
>MADs have completed.  Doesn't change the fact that there isn't anything wrong
>with this part of the code - it works as intended.

The best I can tell is that the reference count is:

number of outstanding mads + 
1 until the user calls destroy +
number of times that a mad has been queued to the cep

unless the cep is for a new connection, in which case it's:

1 until the user calls destroy +
0 while the request callback is being invoked??? +
I have no idea, but at some point, it reverts to the above definition

And it's okay to reference the cep without incrementing the reference count...
I can't even figure out the intent of the code, let alone show that it's a fact
that it works.

>> The __cleanup_cep() call is what sends the DREQ in the first place...
>> The cep enters the function in the established state.
>
>When it falls through to the DREQ_SENT state, cancel the MAD.  That way you
>don't send the DREQ just once if the user is going to wait for the DREP.

ib_cancel_mad() should probably be added after any of the following states:

	case CEP_STATE_LAP_SENT:
	case CEP_STATE_LAP_MRA_RCVD:
	case CEP_STATE_LAP_MRA_SENT:
	case CEP_STATE_DREQ_SENT:

>> I was looking at changing __dreq_cep() to use __cep_send_mad(), which
>> doesn't take a reference on the cep.
>
>Then you affect DREQ processing for all CEPs, even those where the caller will
>wait for the DREP (or DREQ timeout).  You'll effectively break that
>functionality.  What's wrong with canceling the DREQ in the DREQ_SENT case?

dreq_cep() is only called from __cleanup_cep().  A user that wants to wait for a
DREP or a timeout should call al_cep_dreq().

- Sean