[openib-general] Re: [PATCH] ib_mad: prevent duplicateoutstanding MADtransactions with same TID

[Jack Morgenstein]

On Monday 27 February 2006 21:36, Michael S. Tsirkin wrote:
> Quoting Sean Hefty <mshefty at ichips.intel.com>:
> > 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