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