This parameter was added in order to support a proper timeout for
error recovery before the spec defined a periodic keep-alive.
Now that we have periodic keep-alive, we don't need a user configurable
transport layer retry count, the keep-alive timeout is sufficient,
transports can retry for as long as they see fit.
Isn't there some IB protocol level rationale for a low retry count
in various fabric setups?
IIRC the retry count is part of what drives the APM switch over, so
APM configuration should use a lower value.
Completely agree Jason. Lowering the retry_count is very useful
for APM (Automatic Path Migration).
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
