[openib-general] Re: [PATCH] ib_mad: prevent duplicateoutstanding MADtransactions with same TID

[Sean Hefty]

Hal Rosenstock wrote:
> What's the TID issue (separate from the RMPP issues on top of it) ? Is
> it the potential duplication of the TID from different hosts adding
> complexity on the SM/SA side ? Is that a fair assesment ?

If we ignore RMPP, the TID issue as far as I can make out is this.  Duplicate 
requests may be received by a ULP, resulting in duplicate responses.  Looking at 
the code, I think that the only real issue here is some inefficiencies.  (Plus a 
bug that can result in matching RMPP ACKs with the wrong transaction, but this 
is a separate issue.)

Adding in RMPP, the inefficiencies grow.  For example, host A issues a path 
record query, times out, and resends the query.  The SA on the other side 
currently sends two responses, but both responses will have the same TID.  When 
segments are received by host A, he will interpret all segments as belonging to 
one response, with the second response containing duplicated MADs.

What I believe will happen is that one of the responses will be reassembled and 
returned to the user.  On the SA side, all ACKs will match with the first 
response, and the second response will time out, never getting past the first 
segment.

I was thinking about how we can reduce some of the inefficiencies.  Currently, 
we only track if a request is waiting for a response or not.  We can add a new 
state indicating that a response is in progress, which would be set when the 
first segment of a response is received.  This would be used to suppress 
duplicate requests.

On the receive side, I was considering adding an API that the user would invoke 
to indicate that a response was being generated.  The MAD layer would queue this 
information, and a received request would be checked against this queue to 
determine if it were a duplicate.  When the response is sent, the queued 
information would be removed.  I think that we may be able to use such an API to 
support dual-sided RMPP as well.

- Sean