David McMillen wrote:
I would be happy to rework this patch again to make it a proper
example. Please let me know what to change. I read through the
threads referenced below and did not see anything that relates to this
patch.
Over these threads (along with others on which I didn't provide you with
a pointer), people were attempting to discuss the root cause of the
problem and few proposed approaches/solutions. Your patch simply add
retries to a synthetic test program and as I wrote you, I don't have any
comments on it, expect for that this may not an end-in-mind, that's it.
In all versions of rdma_cm, [...] and assuming a properly functioning
fabric, both rdma_resolve_addr and rdma_resolve_route can fail due to
ETIMEDOUT, and both can be retried with success. Is there an example
that I missed somewhere that shows how I should be doing things?
no. In many cases the retry is done in a higher level such as the SCSI
stack or the file system core trying to mount, etc. As I wrote, the
retry for address and route resolution may be implemented in the rdma-cm
and layers below it, but if you feel this is beyond your scope, no
problem, at some point the next generations will have to deal with it.
Or.
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
