> Quoting Sean Hefty <[EMAIL PROTECTED]>: > Subject: RE: [ofa-general] Re: [PATCH] ib/cm: fix stale connection detection > > >> If two REQs are received with matching local IDs, but the REQs > >> themselves differ on one or more fields, such as the QPN, the second REQ > >> is dropped as a duplicate. > > > >Why do you speak about dropping duplicates as a valid response? > > I was only mentioning the current behavior. > > >As far as I can tell, the 2 legal responses to a duplicate REQ > >are resending a REP and rejecting with code 30. > > It's possible to receive a duplicate REQ before processing has completed and a > REP generated to the first REQ. In this case, it makes sense simply to > discard > the duplicate REQ. > > When processing completes on the first REQ, the CM will generate either a REP > or > a REJ, so I believe that the behavior is compliant when handling an actual > duplicate REQs.
Well, in case the second REQ differs from the first one, discarding it might not be the best option: I think we might want to queue it and process when you exit the ephemeural state. -- MST _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
