[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