[PATCH rdma-next] RDMA/cma: Use ACK timeout for RoCE packetLifeTime

[PATCH rdma-next] RDMA/cma: Use ACK timeout for RoCE packetLifeTime

[Dag Moxnes]

The cma is currently using a hard-coded value, CMA_IBOE_PACKET_LIFETIME,
for the PacketLifeTime, as it can not be determined from the network.
This value might not be optimal for all networks.

The cma module supports the function rdma_set_ack_timeout to set the
ACK timeout for a QP associated with a connection. As per IBTA 12.7.34
local ACK timeout = (2 * PacketLifeTime + Local CA’s ACK delay).
Assuming a negligible local ACK delay, we can use
PacketLifeTime = local ACK timeout/2
as a reasonable approximation for RoCE networks.

Signed-off-by: Dag Moxnes <dag.moxnes@oracle.com>
Change-Id: I200eda9d54829184e556c3c55d6a8869558d76b2
---
 drivers/infiniband/core/cma.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index c8566a4237..2c1b08bde2 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -2530,7 +2530,9 @@ EXPORT_SYMBOL(rdma_set_service_type);
  * This function should be called before rdma_connect() on active side,
  * and on passive side before rdma_accept(). It is applicable to primary
  * path only. The timeout will affect the local side of the QP, it is not
- * negotiated with remote side and zero disables the timer.
+ * negotiated with remote side and zero disables the timer. In case it is
+ * set before rdma_resolve_route, the value will also be used to determine
+ * PacketLifeTime for RoCE.
  *
  * Return: 0 for success
  */
@@ -2939,7 +2941,16 @@ static int cma_resolve_iboe_route(struct rdma_id_private *id_priv)
 	route->path_rec->rate = iboe_get_rate(ndev);
 	dev_put(ndev);
 	route->path_rec->packet_life_time_selector = IB_SA_EQ;
-	route->path_rec->packet_life_time = CMA_IBOE_PACKET_LIFETIME;
+	/* In case ACK timeout is set, use this value to calculate
+	 * PacketLifeTime.  As per IBTA 12.7.34,
+	 * local ACK timeout = (2 * PacketLifeTime + Local CA’s ACK delay).
+	 * Assuming a negligible local ACK delay, we can use
+	 * PacketLifeTime = local ACK timeout/2
+	 * as a reasonable approximation for RoCE networks.
+	 */
+	route->path_rec->packet_life_time = id_priv->timeout_set ?
+		id_priv->timeout - 1 : CMA_IBOE_PACKET_LIFETIME;
+
 	if (!route->path_rec->mtu) {
 		ret = -EINVAL;
 		goto err2;
-- 
2.20.1

Re: [PATCH rdma-next] RDMA/cma: Use ACK timeout for RoCE packetLifeTime

[Jason Gunthorpe]

On Fri, Oct 25, 2019 at 01:42:01PM +0200, Dag Moxnes wrote:
> The cma is currently using a hard-coded value, CMA_IBOE_PACKET_LIFETIME,
> for the PacketLifeTime, as it can not be determined from the network.
> This value might not be optimal for all networks.
> 
> The cma module supports the function rdma_set_ack_timeout to set the
> ACK timeout for a QP associated with a connection. As per IBTA 12.7.34
> local ACK timeout = (2 * PacketLifeTime + Local CA’s ACK delay).
> Assuming a negligible local ACK delay, we can use
> PacketLifeTime = local ACK timeout/2
> as a reasonable approximation for RoCE networks.
> 
> Signed-off-by: Dag Moxnes <dag.moxnes@oracle.com>
> Change-Id: I200eda9d54829184e556c3c55d6a8869558d76b2

Please don't send Change-Id to the public lists. Run checkpatch before
sending.

Otherwise this seems reasonable to me..

Jason

Re: [PATCH rdma-next] RDMA/cma: Use ACK timeout for RoCE packetLifeTime

[Dag Moxnes]

Hi Jason,

Den 29.10.2019 20:51, skrev Jason Gunthorpe:
> On Fri, Oct 25, 2019 at 01:42:01PM +0200, Dag Moxnes wrote:
>> The cma is currently using a hard-coded value, CMA_IBOE_PACKET_LIFETIME,
>> for the PacketLifeTime, as it can not be determined from the network.
>> This value might not be optimal for all networks.
>>
>> The cma module supports the function rdma_set_ack_timeout to set the
>> ACK timeout for a QP associated with a connection. As per IBTA 12.7.34
>> local ACK timeout = (2 * PacketLifeTime + Local CA’s ACK delay).
>> Assuming a negligible local ACK delay, we can use
>> PacketLifeTime = local ACK timeout/2
>> as a reasonable approximation for RoCE networks.
>>
>> Signed-off-by: Dag Moxnes <dag.moxnes@oracle.com>
>> Change-Id: I200eda9d54829184e556c3c55d6a8869558d76b2
> Please don't send Change-Id to the public lists. Run checkpatch before
> sending.
>
> Otherwise this seems reasonable to me..
Thanks for the review. Sorry about the Change-Id. I will send a v2 patch 
without it.

Regards,
-Dag
>
> Jason