On Thursday 23 February 2006 09:41, Sean Hefty wrote: > >When RECEIVING: > > If RESPONSE bit is set: > > Need to check TID/class against outstanding requests. > > Otherwise: > > Need to check TID/GID/class against outstanding > >responses (RMPP) > > GID is important here, because responder may have > >several > > RMPP sessions active with same TID, but involving > >different > > Destination hosts. > > What specific error do you see in the receive path? Responses should match > with requests based on TID alone, since we control setting the TID. I can > see where a duplicate request may be received for a response that is > currently in transfer, but that seems like a narrow window. > The error is in the "Otherwise" portion. It is possible for the SA to receive Get-Table requests from different hosts, (for different attributes, even) where the TID is identical between hosts. Currently, in RMPP, the TID alone is used to match (on the responder side) the RMPP session with the received ACKS/NACKS (which do not have the response bit set). In such a case, all the received ACKs/NACKS, from all hosts which are using that TID in simultaneous sessions would be delivered to the earliest RMPP response session.
I'm not sure how rare such a simultaneous-session occurrence would be in a large (thousands of nodes) network, upon, say, network initialization. We are controlling TIDS within a single host, but we are not guaranteeing network-wide uniqueness for TIDS, nor should we, since the IB Spec states (section 13.4.6.4) that the TID/GID/class combination should be unique, not TID alone. - 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
