Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp1717165imc; Fri, 22 Feb 2019 09:52:39 -0800 (PST) X-Google-Smtp-Source: AHgI3Ibv9WU8p/UFS+3rdNh/FsH1hgkvy2bgpt4SZlE4cdQhr0lSRiUtd+hnRknFgFApGqzu7WxF X-Received: by 2002:a62:7042:: with SMTP id l63mr5330196pfc.1.1550857959803; Fri, 22 Feb 2019 09:52:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550857959; cv=none; d=google.com; s=arc-20160816; b=X7w63XCuWAMdVlVe0zrEN90TyA7YnrKu/+DmsGFlU1XnMOoq9Za/f5qBGnSKvvWzWT ZAmQwfQmZecSiX8e19Fi2tj8lQnBEq2WV6UQMQYR8NlJqSevylYD3+iHH7TxOVF5zxk4 R03KNah+VIp7+kQ+jlCSV2ktMnShWYg4ktGVd0UnzCqbAmJcQBYmDo63hfCFMWtJDgTK 6lXDLQbJs3FHiz4m/k5h5PJdlNu+pigatoOot0txMj9Y5DgitOdnl6sXHib6dYp/bHXR ipPhbT1r+ybHlLdoW8qL4J25DRfegd/z5iTYBpF2QRq5D+S2RIXzWoRVp85oRQdZ69BK ojzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:to:cc:in-reply-to:date:subject :mime-version:message-id:from; bh=vTY9YBNEBlNSPvNPpvM8K+898tKFR8hsaJKiZiRjkZ4=; b=jGzIpQApXjiwSw/ZqMsOe9WLSWSTJ436zq18JysIGSunFJR1kCoUsqIsINxxl/UYr0 Z6P1cLY0ifZXezwZ5UPIaajHXNIm33IVqMdmquEixkNvN+kOJAZiT0m/apWglNNqbePx 1psoZoJXtym+dWxJST98xO7ApsiHnXnM8MtqABOMkkxzFPgJMyMPpX0nhK7HqiHQ/Qsv mVewvoCRgV3iBEbZDvl915Go2VPR6YptFYi4vnjHTBjvybmUZh6sWvVivTLnyzBM255I OLR8uUc4AZzI7V1HVE1GUw8lkjJcVgpfgB46KWmtfMr5pY04n3Z3qjixBEBqYR+kiMym 1ncQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q2si1915438pgh.87.2019.02.22.09.52.23; Fri, 22 Feb 2019 09:52:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727046AbfBVRv7 (ORCPT + 99 others); Fri, 22 Feb 2019 12:51:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60800 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725832AbfBVRv6 (ORCPT ); Fri, 22 Feb 2019 12:51:58 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 41F3F3024EA2; Fri, 22 Feb 2019 17:51:58 +0000 (UTC) Received: from [172.31.1.7] (ovpn-112-31.rdu2.redhat.com [10.10.112.31]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2EFE1600CD; Fri, 22 Feb 2019 17:51:57 +0000 (UTC) From: Doug Ledford Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4BA6C486-80C9-4C0B-91AD-B21308731512"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: [PATCH] RDMA/cma: Make CM response timeout and # CM retries configurable Date: Fri, 22 Feb 2019 12:51:55 -0500 In-Reply-To: Cc: Jason Gunthorpe , =?utf-8?Q?H=C3=A5kon_Bugge?= , Leon Romanovsky , Parav Pandit , "linux-rdma@vger.kernel.org" , linux-kernel@vger.kernel.org To: Steve Wise References: <20190217170909.1178575-1-haakon.bugge@oracle.com> <20190222163637.GA9819@ziepe.ca> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Fri, 22 Feb 2019 17:51:58 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Apple-Mail=_4BA6C486-80C9-4C0B-91AD-B21308731512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 22, 2019, at 12:14 PM, Steve Wise = wrote: >=20 >=20 > On 2/22/2019 10:36 AM, Jason Gunthorpe wrote: >> On Sun, Feb 17, 2019 at 06:09:09PM +0100, H=C3=A5kon Bugge wrote: >>> During certain workloads, the default CM response timeout is too >>> short, leading to excessive retries. Hence, make it configurable >>> through sysctl. While at it, also make number of CM retries >>> configurable. >>>=20 >>> The defaults are not changed. >>>=20 >>> Signed-off-by: H=C3=A5kon Bugge >>> drivers/infiniband/core/cma.c | 51 = ++++++++++++++++++++++++++++++----- >>> 1 file changed, 44 insertions(+), 7 deletions(-) >>>=20 >>> diff --git a/drivers/infiniband/core/cma.c = b/drivers/infiniband/core/cma.c >>> index c43512752b8a..ce99e1cd1029 100644 >>> +++ b/drivers/infiniband/core/cma.c >>> @@ -43,6 +43,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>>=20 >>> #include >>> @@ -68,13 +69,46 @@ MODULE_AUTHOR("Sean Hefty"); >>> MODULE_DESCRIPTION("Generic RDMA CM Agent"); >>> MODULE_LICENSE("Dual BSD/GPL"); >>>=20 >>> -#define CMA_CM_RESPONSE_TIMEOUT 20 >>> #define CMA_QUERY_CLASSPORT_INFO_TIMEOUT 3000 >>> -#define CMA_MAX_CM_RETRIES 15 >>> #define CMA_CM_MRA_SETTING (IB_CM_MRA_FLAG_DELAY | 24) >>> #define CMA_IBOE_PACKET_LIFETIME 18 >>> #define CMA_PREFERRED_ROCE_GID_TYPE IB_GID_TYPE_ROCE_UDP_ENCAP >>>=20 >>> +#define CMA_DFLT_CM_RESPONSE_TIMEOUT 20 >>> +static int cma_cm_response_timeout =3D = CMA_DFLT_CM_RESPONSE_TIMEOUT; >>> +static int cma_cm_response_timeout_min =3D 8; >>> +static int cma_cm_response_timeout_max =3D 31; >>> +#undef CMA_DFLT_CM_RESPONSE_TIMEOUT >>> + >>> +#define CMA_DFLT_MAX_CM_RETRIES 15 >>> +static int cma_max_cm_retries =3D CMA_DFLT_MAX_CM_RETRIES; >>> +static int cma_max_cm_retries_min =3D 1; >>> +static int cma_max_cm_retries_max =3D 100; >>> +#undef CMA_DFLT_MAX_CM_RETRIES >>> + >>> +static struct ctl_table_header *cma_ctl_table_hdr; >>> +static struct ctl_table cma_ctl_table[] =3D { >>> + { >>> + .procname =3D "cma_cm_response_timeout", >>> + .data =3D &cma_cm_response_timeout, >>> + .maxlen =3D sizeof(cma_cm_response_timeout), >>> + .mode =3D 0644, >>> + .proc_handler =3D proc_dointvec_minmax, >>> + .extra1 =3D &cma_cm_response_timeout_min, >>> + .extra2 =3D &cma_cm_response_timeout_max, >>> + }, >>> + { >>> + .procname =3D "cma_max_cm_retries", >>> + .data =3D &cma_max_cm_retries, >>> + .maxlen =3D sizeof(cma_max_cm_retries), >>> + .mode =3D 0644, >>> + .proc_handler =3D proc_dointvec_minmax, >>> + .extra1 =3D &cma_max_cm_retries_min, >>> + .extra2 =3D &cma_max_cm_retries_max, >>> + }, >>> + { } >>> +}; >> Is sysctl the right approach here? Should it be rdma tool instead? >>=20 >> Jason >=20 > There are other rdma sysctls currently: net.rdma_ucm.max_backlog and > net.iw_cm.default_backlog. The core network stack seems to use sysctl > and not ip tool to set basically globals. >=20 > To use rdma tool, we'd have to have some concept of a "module" object, = I > guess. IE there's dev, link, and resource rdma tool objects = currently. > But these cma timeout settings are really not per dev, link, nor a > resource. Maybe we have just a "core" object: rdma core set > cma_max_cm_retries min 8 max 30. I don=E2=80=99t know, I think you make a fairly good argument for = leaving it as a sysctl. We have infrastructure in place for admins to = set persistent sysctl settings. The per device/link settings need = something different because link names and such can change. Since these = are globals, I=E2=80=99d leave them where they are. -- Doug Ledford GPG KeyID: B826A3330E572FDD Key fingerprint =3D AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 = 2FDD --Apple-Mail=_4BA6C486-80C9-4C0B-91AD-B21308731512 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEErmsb2hIrI7QmWxJ0uCajMw5XL90FAlxwNrsACgkQuCajMw5X L91MUQ/+MjIJrwP4Fk2DhC51GXAluuZm6ZQzT0syjc9g9mhA3XFMc2Tba1vLbxxB 0TXfg9cKfk5thLnkJOCKAmT/ozabScXSUbN+wfc1ulD9BakRAjqvlgrRmVOf0yzP fXSWZutRLthmFYi4QlHm2c4umGFV7D/YAaDXjGCNLP17haYulKpwm+ucKq0+ZYLP QhQPwsHystna5RtDxFGAlDqZEF+PcBwMyu6z2n/mAf/t5EPqiP8U48s6DyaE9mWj 6Xb40Kf3YilGqLaOumetu8Q/gZtDoszH8YHaQ2UE1ie7V7qnltMEcBJjr5St+pul y127TUBdLQEh8lyCxfxPqWAKvquhxZ1jynG5cnOeVXgGjeSAPe4mGFVw0XAuGFTP gUavNDUm5ZrtMpZaqB3L6H83/VdWoHi1pCJhmkSE17aM6q2bBe4SmFzrazBstoQ4 loQrzIiChmuQRKvl8UV+YYIkMtix6tipNb9GQPDO78JWKYG58h/S5nY7hkVlhSG8 rQjq9JaapXpRZ0784e5603QM0OzD7QCwxxhupw/CwOsmAi4LoXSogteAljQTnaku chYzJ7xZMEKYMx3SJH6RMfO32+rxKgxlqAOs6kn7dF6/N0IQ0NZ1+2r0IeO6ZPOI jPWTZlG0JfiNp+s91OjdaXJvf+g+nue5QQABQB3BcAZUnjzDCcg= =lEPj -----END PGP SIGNATURE----- --Apple-Mail=_4BA6C486-80C9-4C0B-91AD-B21308731512--