On Thu, Dec 16, 2004 at 02:51:29PM -0800, Sean Hefty wrote: > Libor Michalek wrote: > > On Thu, Dec 16, 2004 at 12:14:18PM -0800, Sean Hefty wrote: > > > >>One final note, I'm hoping that a more abstracted CM could be layered > >>on top of this one, if it were desired. E.g. one that performs QP > >>transitions, automatically generates MRAs, retries requests, etc. > > > > > > Are you suggesting that this proposed CM layer would not be responsible > > for retries and timeouts? I'm not sure how useful that would be, seems > > like every CM consumer would need/want these capabilities. > > I was trying to match the existing MAD API. The CM would perform > timeouts, but not retries. Consumers could retry request immediately > upon notification of a timeout. This lets the client change the > timeout value. (I'm negotiable on this, but the cost of having clients > initiate retries is basically one function call.)
I was thinking the cost is a bit higher then a function call. The data used to generate the CM MAD needs to be stored somewhere to generate the retry if necessary. I'll need to take a closer look at which parameters your expecting from the consumer and which you are going to save as part of the internal CM connection structure. > I have given some thought to how retries should work. I've thought > about adding a new call, ib_retry_cm_send() - or something like that, > that resends the last message sent. Or the callback could indicate to > retry. Oh, so the CM would have enough information to generate the retry, but the consumer would need to notify the CM to do so? -Libor _______________________________________________ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
