> In the spec, a normal flow to close a connection is > at the client side: State "Established" ---- send DREQ ---> > State "DREQ sent" --- receive DREP ---> State "TimeWait" ---> > State "Idle"
Yes - the CM kernel code follows this state machine. > According to the code and tests I did, it seems that ib_cm doesn't > wait for DREP and goes directly from "DREQ sent" into "TimeWait". This can happen in specific situations, such as errors, if the user destroys the cm_id without waiting for the DREP (treated as a DREQ timeout), or if both sides initiate a DREQ. > I think that this is a bug, am I right? I don't see that the code follows the behavior that you're describing. In ib_send_cm_dreq(), the cm_id state changes to DREQ_SENT. In cm_drep_handler() (called when a DREP is received), the cm_id state is verified to be DREQ_SENT, then transitioned to TIMEWAIT. If you can describe the test details more, I can try to find the most likely code path that's being hit. It's possible that you're hitting one of the situations mentioned above. - Sean _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
