[openib-general] [PATCHv2][RFC] kDAPL: use cm timers instead of own

[Tom Duffy]

On Thu, 2005-05-26 at 22:25 -0700, Sean Hefty wrote:
> >So, here is the strategy I am taking.  Please let me know if it is
> >wrong.
> >
> >When dapl_ep_connect() is called, I save off the timeout value into the
> >dapl_ep struct.  Then, when we get ready to call ib_send_cm_req(), I
> >stuff the timeout value (after munging it into IB's strange format) into
> >the conn params remote_cm_response_timeout.
> 
> From a CM perspective, this sounds fine.  Note that the CM timeout will not
> occur until the number of retries has been met.  So I don't know if the
> timeout passed to dapl_ep_connect() should convert directly into the
> remote_cm_response_timeout, or needs to be divided by the number of retries.

So, are you saying that if you have a timeout of 4 seconds (you pass in
20) and you have retries set to 2, that it will fail after 8 seconds?

James, what is the timeout value passed into dapl_ep_connect mean, the
total timeout time?  Or how much for each retry?

Also, did you notice that dapl_ib_connect always sets the timeout to 20
(4 seconds) no matter what?  Should this be the case?

> >If the connection fails to complete within the timeout,
> >dapl_cm_active_cb_handler() is called with IB_CM_REQ_ERROR which in turn
> >calls dapl_evd_connection_callback() which does the same thing that
> >dapl_ep_timeout() used to do -- tear down the connection.
> 
> I haven't looked at your changes, but note that calling ib_destroy_cm_id
> from within the CM callback thread will hang.  The callback holds a
> reference on the cm_id.  The good news is that there should be code in kDAPL
> to catch this.

I will take a look and see if this could happen.

-tduffy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050527/10789bf7/attachment.sig>