[openib-general] Re: [openib-commits] r2695 - gen2/users/jlentini/linux-kernel/dat-provider

[James Lentini]

On Fri, 24 Jun 2005, Hal Rosenstock wrote:

> On Thu, 2005-06-23 at 15:18, jlentini at openib.org 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 <jlentini at netapp.com>
>>
>>
>> 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.