[openib-general] RFC: detecting duplicate MAD requests
Hal Rosenstock
halr at voltaire.com
Mon May 1 08:05:44 PDT 2006
On Sat, 2006-04-29 at 02:23, Sean Hefty wrote:
> >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.
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 ?
> 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 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.
C13-18.1.1 defines a new operation. Isn't the case you are describing is
responding to an existing operation ?
> >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.
Why not ? Wouldn't the second response not match anything in the client
on the request side ?
-- Hal
> - Sean
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
More information about the general
mailing list