Get rid of transport layer retry count config parameter
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] Get rid of transport layer retry count config parameter
Quoted 10 lines
Quoted 7 lines
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?
None that I know of... The QP retry count determines the time it would take to fail a send/read/write.. The retry_count value is multiplied with the packet timeout (which is a result of an IB specific computation - managed by the CM).
It's useful when one needs to limit the time until a send fails in order to kick error recovery (useful for srp which doesn't implement periodic keep-alive), but since nvme does, I don't see the reason why RDMA or any other transport should expose this configuration as the keep-alive timeout exists for that.