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

[Sean Hefty]

>> For example, as soon as the user calls connect(), can they receive a CLOSE
>> event, even before the connect() call returns?
>
>No.  connect results in a CONNECT_REPLY event always. Not a CLOSE
>event.

What if the remote side sends the reply, then decides to abort or disconnect?
I'm considering a case where multiple events may be queued.  I.e. after calling
connect(), what events can a user see without making any other calls?

>> If so, are there any issues
>> here?  Is it possible for the user to call down to the provider, after the
>> provider has generated a CLOSE event, resulting in accessing the wrong
>> connection, or crashing in the provider?
>
>The IWCM prevents this, methinks, by failing any downcalls once the
>cm_id is no longer in a CONNECTED state.

The issue is that a state check could succeed, with the downcall pending when an
event is received that changes the state.  The downcall cannot be stopped at
this point, and will hit the provider's code.  Maybe the call/event model
prevents this from ever being an issue?

>For orderly close, the provider needs to wait until the close completes
>or is aborted due to protocol errors.  This can be implemented in many
>ways, but blocking the caller is perhaps the simplest.  Also, note, that
>the QP needs to stay around until it transitions out of CLOSING by the
>provider.  This further complicates things and is different from IB.

As long as the blocking is reasonably short, this sounds fine.  I'm thinking
more of the case where a module is trying to release its resources before being
unloaded.

>connect(), listen(), and when incoming iwarp connections get
>established.

I didn't consider that last case.  The provider creates the context at this
point, but when is it associated with the cm_id?  On accept()?  How are
additional events that are generated in this case handled, or is that even
possible?  I.e. you've notified the user of a new connection request, when the
connection is aborted.  The user hasn't called accept() or reject() yet.

- Sean