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

[Tom Tucker]

On Wed, 2006-03-22 at 15:51 -0800, Sean Hefty wrote:
> >The user, being the IWCM, will always see a CONNECT_REPLY to a connect
> >downcall.
> 
> I understand that a CONNECT_REPLY event is generated in response to calling
> connect().  But can any events (e.g. CLOSE) follow that without the user taking
> any other action?

Yes. I think there are two possibilities involving close: CLOSE
(abortive shutdown) and DISCONNECT followed by CLOSE (graceful
shutdown). Either of these could happen if the remote peer issued
iw_cm_disconnect after iw_cm_accept'ing the connection and before 
the local user did anything.

BTW, if the CONNECT_REPLY was delivered with a status of RESET or
REJECT, no other events should be received on this cm_id because it
would never have transitioned to the ESTABLISHED state. The previous
paragraph applies when CONNECT_REPLY was delivered with a status of
ACCEPT (0). 

> 
> >> 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.
> >>
> >
> >The provider must handle this and _not_ pass any events up until the
> >IWCM has accepted or rejected the connection request.  In the case of an
> >connect request upcall, followed by a connection abortion, followed by a
> >accept_cr downcall, the accept_cr downcall would return an error like
> >-ECONNRESET.  OR the provider could allow the accept_cr to succeed,
> >which moves everything to RTS/CONNECTED, then generate a CLOSE upcall.
> >Either way is correct methinks.  I think providers would do the former.
> 
> Okay - this sounds like this case is handled.
> 
> So, I'm trying to determine when a CLOSE event will be generated, and I _think_
> it's in these two cases:
> 
> 1. After calling connect(), and a successful CONNECT_REPLY event.
> 2. After calling accept().
> 

The CLOSE event must delivered exactly once after the connection has
gone to established (but more precisely, the QP --> RTS). 

> Then trying to determine if there are any races here with the user destroying
> the cm_id at any time.

There may be. But I'd like some consensus that these races represent
bugs and not architectural flaws. That is, the approach is ok, but my
code stinks. Then we can move forward incrementally fixing bugs instead
of ripping up the carpet and starting over on concrete.

> 
> - Sean
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general