On Fri, 24 Jun 2005, Hal Rosenstock wrote:
On Thu, 2005-06-23 at 15:18, [EMAIL PROTECTED] wrote:
Author: jlentini
Date: 2005-06-23 12:18:14 -0700 (Thu, 23 Jun 2005)
New Revision: 2695
Modified:
gen2/users/jlentini/linux-kernel/dat-provider/dapl_openib_cm.c
Log:
Retry normal packets but not the CM messages. CM message retries are
linked to dat_ep_connect()'s timeout value
Signed-off-by: James Lentini <[EMAIL PROTECTED]>
Modified: gen2/users/jlentini/linux-kernel/dat-provider/dapl_openib_cm.c
===================================================================
-- gen2/users/jlentini/linux-kernel/dat-provider/dapl_openib_cm.c
2005-06-23 19:15:12 UTC (rev 2694)
+++ gen2/users/jlentini/linux-kernel/dat-provider/dapl_openib_cm.c
2005-06-23 19:18:14 UTC (rev 2695)
@@ -39,10 +39,10 @@
...
#define DAPL_IB_CM_RESPONSE_TIMEOUT 20 /* 4 sec */
-#define DAPL_IB_MAX_CM_RETRIES 4
+#define DAPL_IB_MAX_CM_RETRIES 0
Until the algorithm previously discussed is implemented, changing
DAPL_IB_MAX_CM_RETRIES to 0 makes this more frail (in the case of a lost
REQ, etc.).
I made this change because this is what we intended to do in the
original "timeout implementation" change. I've added an item to the
TODO list to account for address resolution time and CM retries in
the timeout value.
In my testing, the lack of retries hasn't been an issue. If it is, we
can boost it up and account for it in the timeout value.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
