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@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general