> > > > The problem is that we can't synchronously cancel an > > outstanding connect request. Once we've asked the adapter to > > connect, we can't tell him to stop, we have to wait for it to > > fail. During the time period between when we ask to connect > > and the adapter says yeah-or-nay, the user hits ctrl-C. This > > is the case where disconnect and/or destroy gets called and > > we have to block it waiting for the outstanding connect > > request to complete. > > > > One alternative to this approach is to do the kfree of the > > cm_id in the deref logic. This was the original design and > > leaves the object around to handle the completion of the > > connect and still allows the app to clean up and go away > > without all this waitin' around. When the adapter finally > > finishes and releases it's reference, the object is kfree'd. > > > > Hope this helps. > > > Why couldn't you synchronously put the cm_id in a state of > "pending delete" and do the actual delete when the RNIC > provides a response to the request?
This is Tom's "alternative" mentioned above. The provider already keeps an explicit reference on the cm_id while it might possibly deliver an event on that cm_id. So if you change deref to kfree the cm_id on its last deref (when the refcnt reaches 0), then you can avoid blocking during destroy... > There could even be > an optional method to see if the device is capable of > cancelling the request. I know it can't yank a SYN back > from the wire, but it could refrain from retransmitting. I would suggest we don't add this optional method until we see an RNIC that supports canceling a connect request or accept synchronously... Steve. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html