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

Hal Rosenstock halr at voltaire.com
Tue May 31 11:28:32 PDT 2005


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) ?

>  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.

-- 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
> >




More information about the general mailing list