[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