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

[James Lentini]

On Tue, 31 May 2005, Hal Rosenstock wrote:

> On Tue, 2005-05-31 at 14:17, James Lentini wrote:
>> Here's the specification's exact description:
>>
>>   timeout: Duration of time, in microseconds, that a consumer waits for
>>            connection establishment. The value of DAT_TIMEOUT_INFINITE
>>            represents no timeout, indefinite wait. Values must be
>>            positive.
>>
>> My perspective is that we are not implementing this API for a real 
>> time operating system and therefore should take a fuzzy view of 
>> time.
>
> Fuzzy in that we are certainly not concerned with the granularity of 
> microseconds.
>
>> My interpretation of the definition above is that a provider should 
>> attempt to establish a connection for a least [timeout] time.
>
>
> So any number of retries is allowed up to the time period specified 
> (depending on the timeout used) ?

Correct, any number of retries (including 0) is allowed. Once the time 
period expires, the provider should post a result as quickly as 
possible.

>>  If a connection is not established after attempting for at least 
>> [timeout] time, the provider should should give up and post a 
>> connection failure event. If there is some reasonable additional 
>> time needed for address resolution, etc., I think that is 
>> acceptable.
>
> This all can be bundled in. One just needs to know what the 
> requirement is.

If we included address resolution, how would we divide up the time 
between address resolution and cm protocol? Wouldn't we have to 
track how long address resolution took to complete?

> -- Hal
>
>> james
>>
>> On Tue, 31 May 2005, Hal Rosenstock wrote:
>>
>>> On Tue, 2005-05-31 at 13:27, James Lentini wrote:
>>>>> James, what is the timeout value passed into dapl_ep_connect mean, the
>>>>> total timeout time?  Or how much for each retry?
>>>>
>>>> It is the total timeout value.
>>>
>>> Total meaning all everything inclusive ? If that is what it is supposed
>>> to be, that is not what is implemented now:
>>>
>>> DAPL_IB_CM_RESPONSE_TIMEOUT 20 /* 4 sec */
>>> DAPL_IB_MAX_CM_RETRIES 4
>>>
>>> There are also the timeout/retries of IBAT as well.
>>> DAPL_IB_MAX_AT_RETRY 3
>>> IB_AT_REQ_RETRY_MS      100
>>>
>>> -- Hal
>>>
>