From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Ledford Subject: Re: [PATCH v2] RDMA/cma: Make CM response timeout and # CM retries configurable Date: Thu, 13 Jun 2019 12:32:24 -0400 Message-ID: <08deb91f7516b4c8911211499a00a58392d65a8b.camel@redhat.com> References: <20190226075722.1692315-1-haakon.bugge@oracle.com> <174ccd37a9ffa05d0c7c03fe80ff7170a9270824.camel@redhat.com> <2c114313-01fe-6d4d-5134-592d1a7b829b@acm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-0AQ/OTcN7UdTwkCoV3sM" Return-path: In-Reply-To: <2c114313-01fe-6d4d-5134-592d1a7b829b@acm.org> Sender: linux-kernel-owner@vger.kernel.org To: Bart Van Assche , =?ISO-8859-1?Q?H=E5kon?= Bugge , Jason Gunthorpe , Leon Romanovsky , Parav Pandit , Steve Wise Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org List-Id: linux-rdma@vger.kernel.org --=-0AQ/OTcN7UdTwkCoV3sM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2019-06-13 at 08:28 -0700, Bart Van Assche wrote: > On 6/13/19 7:25 AM, Doug Ledford wrote: > > So, to revive this patch, what I'd like to see is some attempt to > > actually quantify a reasonable timeout for the default backlog > > depth, > > then the patch should actually change the default to that > > reasonable > > timeout, and then put in the ability to adjust the timeout with > > some > > sort of doc guidance on how to calculate a reasonable timeout based > > on > > configured backlog depth. >=20 > How about following the approach of the SRP initiator driver? It > derives=20 > the CM timeout from the subnet manager timeout. The assumption > behind=20 > this is that in large networks the subnet manager timeout has to be > set=20 > higher than its default to make communication work. See also=20 > srp_get_subnet_timeout(). Theoretically, the subnet manager needs a longer timeout in a bigger network because it's handling more data as a single point of lookup for the entire subnet. Individual machines, on the other hand, have the same backlog size (by default) regardless of the size of the network, and there is no guarantee that if the admin increased the subnet manager timeout, that they also increased the backlog queue depth size. So, while I like things that auto-tune like you are suggesting, the problem is that the one item does not directly correlate with the other. --=20 Doug Ledford GPG KeyID: B826A3330E572FDD Key fingerprint =3D AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD --=-0AQ/OTcN7UdTwkCoV3sM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEErmsb2hIrI7QmWxJ0uCajMw5XL90FAl0CepgACgkQuCajMw5X L93+Mw/6A61mDk+ikAXS6vmFqzcWR0dtVmtxKeNB1/IKvTOJ4JZJxnaYaVIrCjzE dn3S3UH0Y3ulfyq90Rl3o9opmes7P0vuL+yvxV8Z75EfSObyrFddWfa3JubQ1j6+ Qn5OygYPCpW6hL1xV8VjT9f4od+BKUglDkkD9SHIWPaZWVEwLzM1b3EDSLxLFX4u kk71uM2PEgxjc3ZSUOSGJrmWEQsM3G/nTshnDD47DJl9PcYx1CUQq6z4aouVQsD0 IlBm6xnWjlfO5qNlCJDXEtKmZgKvI/r1r8+xdz8IicTtmDNaXxxoJX4kP5KNbo4l W0a9FogbmLhkpigzG0EqOkFUlJkvS/rPvancckDaNMX8YWh3uYrt1v+BKecgw0Rp tzGLkDJSoqsmsxZc2as0fUz4CmxA5cPypi+wPQ7LFc2JyfVpdYCGsoiwIwVP7r29 R0dmZNfnVp78QEEcKHmRMVjaRNVzbEYiE2+4Y8MZ7IgB3YBqNgQqByhbha++wFry BXZlf8isVQdeZlYl1QFczlOENrPrYLcz8tPt4eFxheWy8mmLgBboX5otxI0nn4jQ jR7qBUtefDDwmDyOw1++jVg1TI9yTxtfD7W4avzg7Z7R7WlsipO3X91VZjWSFDXu qfE+tzXZx2jCudHaU5e4n0Hp8pE+f+GLERIhPcTAjr6RIuJl78k= =6Yw4 -----END PGP SIGNATURE----- --=-0AQ/OTcN7UdTwkCoV3sM--