It's workable, although I really wish there was a way to handle "stupid" apps that aren't written to handle a busy response.
-----Original Message----- From: Hefty, Sean [mailto:sean.he...@intel.com] Sent: Tuesday, June 08, 2010 12:44 PM To: Jason Gunthorpe Cc: Mike Heinz; linux-rdma@vger.kernel.org; e...@openfabrics.org Subject: RE: [PATCH] Handling busy responses from the SA > Also, I guess, it would be a good API choice if the caller could say > 'get me a reply for this mad or error within 60s' rather than specify > details like retry counts, etc. The timeout values should be globally > set and derived from the usual SA provided data for network transits... I agree with this. Within the framework of the existing umad ABI, this could be specified by setting the high bit in the ib_user_mad_hdr:timeout_ms field, assuming that no one is using that bit in practice. The kernel could then freely select the retry/timeout policy for these clients, which for starters could include dropping BUSY responses and adjusting the timeout using an approach similar to what Mike mentioned in a separate email. Kernel clients could be updated to use this new mode. Any disagreements to this approach? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
