>You can't add this kind of thing piecemeal to a protocol and have it >work. If the sender doesn't see a response (perhaps the response was >lost, or was slow coming), and sends another MAD, this 2nd MAD will >have a different sequence number. How does the recipient know it's the
If a MAD is sent with a different sequence number (transaction ID), then it's a different transaction or request. 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. The MAD layer cannot allow the duplicate response to be sent because of RMPP issues. The most efficient solution is to detect the duplicate request, and avoid all of the processing overhead of generating a response that must be discarded. No change to the MAD protocol is being proposed. Ib_free_recv_mad() already exists, and must be called by each client. The only change being proposed is that until ib_free_recv_mad() is called, another message with the same TID, SGID, and mgmt class is treated as a duplicate. I believe that this is consistent with C13-18.1.1. >same request? If the response was lost the first time, eating the 2nd >MAD without sending a response will result in another timeout and a >3rd MAD... so maybe the recipient remembers the response and sends it The proposal is to only discard duplicate requests while a response to the first request is being generated. Just because a client sends a request 3 times before we can send a response doesn't mean that we need to send 3 responses. Such an implementation is suboptimal, and the responses that are of most concern use RMPP anyway. >Really, it's up to the MAD client to deal with duplicates in its own >way. A client is still restricted from sending a duplicate response while a previous response is in progress. RMPP cannot handle this case. - 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
