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

[Hal Rosenstock]

On Tue, 2005-06-14 at 09:36, Talpey, Thomas wrote:
> At 08:41 AM 6/14/2005, Hal Rosenstock wrote:
> >The current implementation is:
> >1. address resolution phase for some amount of time 
> >followed by:
> >2. dapl_ib_connect timeout * 5 (since there are 4 retries)
> >
> >A better algorithm would be to divide down the timeout by some number of
> >retries (which would vary based on the timeout requested) and have the
> >number of retries vary based on the total timeout requested.
> 
> Why is address resolution exempt from the timeout? If the caller
> wants a timeout, it should be independent of low-level link resolution.
> Socket connect()s don't care about ARP, for example.

I was just stating the way the algorithm is right now. The address
resolution phase can be included in the calculation but this complicates
things a little. 

I thought it was previously said that the timeout can be approximate.
Also, the CM timeouts are approximate and not precise either.

> I don't like the idea of retry counts because there is no deterministic
> length of time that they will take. 

Are you proposing that the number of retries be set to 0 then
(regardless of the timeout requested) ?

> Exponential backoff could drive
> even a few retries to many minutes. Of course, if an IB provider
> can guarantee that N retries will be performed in M seconds, then
> okay, but not in general.

The CM is not using exponential backoff.

-- Hal