[ofw] CM ref counting issues...

[Fab Tillier]

Hi Sean

Hefty, Sean wrote on Thu, 17 Dec 2009 at 07:55:22

>>> For example, in my testing, a REP mad was completed as canceled;
>> 
>> A REP?  If a REP times out, why aren't you ending up sending a REJ and
>> aborting the connection?
> 
> The RTU for a connection can be lost, but the connection still formed.
> An app will see transferred data on the QP.  If the app then issues a
> DREQ, the state transitions to DREQ_SENT.  This is the state that the
> connection is in when the send callback is invoked for the REP.  The
> connections are much shorter lived than the CM message timeouts are in
> this case.

The app (in this case ndconn) doesn't (or isn't supposed to) send the 'pong' message until Accept has completed, so the disconnect shouldn't happen until after the 'ping' is received, the 'pong' is sent and completed (which is delayed by accept completeing.)

Likewise, the client side of ndconn will wait until the 'ping' is received before disconnecting.

Lastly, al_cep_dreq will fail if the CEP is not established, so the app probably didn't initiate sending the DREQ (unless it did it by destroying the CEP.)

> I would need to double check, but I thought the REP completed as
> canceled, not timed out.

Ahh, ok.  I don't think we get the communication established event in this case since that should only happen while we're in RTR, not RTS, and the QP is transitioned to RTS right away, isn't it?  Or do you delay the RTS transition until the RTU is received in WinVerbs?

>> Not sure I quite follow here... The DREQ_SENT state should have invoked
>> the callback.
> 
> This is a mad completion callback, not a cep state callback.  The mad
> was a REP, but the state was a DREQ_SENT.  This was the case I
> observed, but I'm pretty sure that other, similar problems exist.

I think we need to have a better understanding of what's going on.  We're getting closer, but not quite there yet (at least I don't fully understand yet.)

-Fab