>> There is a real issue that is seen when a duplicate request (same TID, SGID, >> mgmt class) is received at the client, resulting in a duplicate response. > >You had mentioned in the previous email on this that this was the case >of a slow responder. Is the responder slow but playing by the IB >timeouts in effect or is it violating those timeouts ?
I don't believe that the responder is violating any timeouts. >> The MAD layer cannot allow the duplicate response to be sent because of RMPP >issues. > >Is this different for non RMPP MADs v. RMPP MADs ? Is the RMPP issue >what you mention below (RMPP receiving a duplicate response) ? If so, is >this an implementation or architecture issue or both ? The issue is a result of the RMPP architecture, but I wouldn't say that RMPP has an issue. It's simply a matter that you can't reassemble multiple MADs from the same source that use the same transaction ID. For non-RMPP MADs, the only issue is one of efficiency. A duplicate response would just be dropped on the requester side if the first response is received. >> A client is still restricted from sending a duplicate response while a >previous >> response is in progress. RMPP cannot handle this case. > >Why not ? Wouldn't the second response not match anything in the client >on the request side ? This is true if the first response completes before the second response is sent. The problem is when both responses are active at the same time. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
