From: Vlad Dumitrescu <vdumitrescu@xxxxxxxxxx> ib_modify_mad with non-zero timeout is used exclusively for CM MRA [1]. The timeout is computed as the sum of the local timeout (set via cm_init_av_by_path) and a constant 60s+ Service Timeout (CMA_CM_MRA_SETTING) passed via the MRA message by the remote. MRAs are generated when duplicate messages are received. Overwriting send_buf.timeout_ms means the MRA Service Timeout requested by the remote will apply to all remaining retry attempts. This can lead to unnecessary and extreme delays when a receiver is only temporarily overloaded. Do not save the MRA timeout so that it only applies to the next retry. ib_modify_mad is also called with a zero timeout, to implement ib_cancel_mad. The timeout was also saved in that case, but it is not required as timeout_sends will skip the retry_send (which reads the saved value) call anyway, based on the non-successful status. [1] IBTA v1.7 - Section 12.6.6 - MRA - Message Receipt Acknowledgment Signed-off-by: Vlad Dumitrescu <vdumitrescu@xxxxxxxxxx> Reviewed-by: Sean Hefty <shefty@xxxxxxxxxx> Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxx> --- drivers/infiniband/core/mad.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c index 86e846b12e2f..bcfbb2a5c02b 100644 --- a/drivers/infiniband/core/mad.c +++ b/drivers/infiniband/core/mad.c @@ -2623,7 +2623,6 @@ int ib_modify_mad(struct ib_mad_send_buf *send_buf, u32 timeout_ms) if (!timeout_ms) mad_send_wr->status = IB_WC_WR_FLUSH_ERR; - mad_send_wr->send_buf.timeout_ms = timeout_ms; if (mad_send_wr->state == IB_MAD_STATE_SEND_START || (mad_send_wr->state == IB_MAD_STATE_QUEUED && timeout_ms)) mad_send_wr->timeout = msecs_to_jiffies(timeout_ms); -- 2.47.0
