The problem is that none of the apps **do** handle BUSY - at all - and your proposal still requires the apps to be changed to stop them from degrading the fabric.
The whole benefit of this change is that it implements a reasonable default without requiring the apps be changed, but still allows them to override the behavior if desired. -----Original Message----- From: Hefty, Sean [mailto:[email protected]] Sent: Wednesday, August 11, 2010 1:00 PM To: Mike Heinz; [email protected]; Roland Dreier; Jason Gunthorpe; Hal Rosenstock Cc: Todd Rimmer Subject: RE: Update proposal for handling BUSY responses from the SA/SM > In addition to the patch itself, there has been significant discussion > about changing the APIs to allow the application to explicitly specify how > to handle BUSY. The current code allows an app to explicitly handle BUSY replies, so we don't need changes for that. I was advocating making things simpler for the user, with more intelligent retry/timeout handling done in the kernel. For example: umad_send() takes the timeout_ms and retries as int. If a negative timeout_ms is given with retries set to 0, then the timeout is treated as the total amount of time to wait for a response. The number of retries and timeout values between each one would be handled by the kernel. This includes the kernel handling BUSY responses in whatever way seems most appropriate. The kernel can be updated to use random retry intervals, exponential back-offs, windowing techniques, response time history, etc. Of course, we can start with some simple kernel changes at first, then enhance them. - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
