On Monday 27 February 2006 21:36, Michael S. Tsirkin wrote: > Quoting Sean Hefty <[EMAIL PROTECTED]>: > > As long as all of the ACKs match to the same RMPP response transaction, > > this should be okay. Some of the ACKs will be interpreted as > > old/duplicates and be discarded. The first response should be > > reassembled on the requester side. Additional responses may time out > > waiting for an ACK that gets matched to another request, but that > > shouldn't matter. > > > > If this is not the case, I'd like to understand why this isn't happening. > > There may be a more serious issue that we're overlooking. > If one of the duplicate sessions on the responder side gets the ACK, it will issue an abort, because the segment being ACKed has not yet been sent by that duplicate session.
In this case, the requester will abort the receiving session, with an S2B status code (IB Spec 13.6.2.2, page 774) -- even though the transfer might have been properly completed if the primary responder session had received the ACK instead of one of the duplicate sessions. Which session actually receives the ACK is a toss-up, since when a session sends a segment, it is placed (upon send completion) at the tail of the wait queue. Thus, arriving ACKs will likely be routed (based upon TID only) to one of the duplicate sessions. -- Jack _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
