[openib-general] RFC: detecting duplicate MAD requests
Sean Hefty
sean.hefty at intel.com
Fri Apr 28 23:23:44 PDT 2006
>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
More information about the general
mailing list