Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: [PATCH v2] svcrdma: Ignore source port when computing DRC hash
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <20190611150116.4209.63309.stgit@klimt.1015granger.net>
Date:   Wed, 19 Jun 2019 16:25:57 -0400
Cc:     linux-rdma@vger.kernel.org,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FAF5EE39-8B5D-4F5C-9E9E-8FCA6EED8378@oracle.com>
References: <20190611150116.4209.63309.stgit@klimt.1015granger.net>
To:     Bruce Fields <bfields@fieldses.org>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Jun 11, 2019, at 11:01 AM, Chuck Lever <chuck.lever@oracle.com> =
wrote:
>=20
> The DRC appears to be effectively empty after an RPC/RDMA transport
> reconnect. The problem is that each connection uses a different
> source port, which defeats the DRC hash.
>=20
> Clients always have to disconnect before they send retransmissions
> to reset the connection's credit accounting, thus every retransmit
> on NFS/RDMA will miss the DRC.
>=20
> An NFS/RDMA client's IP source port is meaningless for RDMA
> transports. The transport layer typically sets the source port value
> on the connection to a random ephemeral port. The server already
> ignores it for the "secure port" check. See commit 16e4d93f6de7
> ("NFSD: Ignore client's source port on RDMA transports").
>=20
> The Linux NFS server's DRC resolves XID collisions from the same
> source IP address by using the checksum of the first 200 bytes of
> the RPC call header.
>=20
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> Cc: stable@vger.kernel.org # v4.14+
> ---
> net/sunrpc/xprtrdma/svc_rdma_transport.c |    7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>=20
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c =
b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> index 027a3b0..0004535 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> @@ -211,9 +211,14 @@ static void handle_connect_req(struct rdma_cm_id =
*new_cma_id,
> 	/* Save client advertised inbound read limit for use later in =
accept. */
> 	newxprt->sc_ord =3D param->initiator_depth;
>=20
> -	/* Set the local and remote addresses in the transport */
> 	sa =3D (struct sockaddr =
*)&newxprt->sc_cm_id->route.addr.dst_addr;
> 	svc_xprt_set_remote(&newxprt->sc_xprt, sa, svc_addr_len(sa));
> +	/* The remote port is arbitrary and not under the control of the
> +	 * client ULP. Set it to a fixed value so that the DRC continues
> +	 * to be effective after a reconnect.
> +	 */
> +	rpc_set_port((struct sockaddr *)&newxprt->sc_xprt.xpt_remote, =
0);
> +
> 	sa =3D (struct sockaddr =
*)&newxprt->sc_cm_id->route.addr.src_addr;
> 	svc_xprt_set_local(&newxprt->sc_xprt, sa, svc_addr_len(sa));

Hi Bruce, what's the disposition of this patch?


--
Chuck Lever