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 > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
