From patchwork Thu Jul 9 20:42:27 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Chuck Lever III X-Patchwork-Id: 6758981 Return-Path: X-Original-To: patchwork-linux-rdma@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id D7D1EC05AC for ; Thu, 9 Jul 2015 20:42:34 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E3B142078F for ; Thu, 9 Jul 2015 20:42:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F2D582078A for ; Thu, 9 Jul 2015 20:42:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753974AbbGIUmb (ORCPT ); Thu, 9 Jul 2015 16:42:31 -0400 Received: from mail-qg0-f54.google.com ([209.85.192.54]:33377 "EHLO mail-qg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753891AbbGIUmb (ORCPT ); Thu, 9 Jul 2015 16:42:31 -0400 Received: by qgef3 with SMTP id f3so70915626qge.0; Thu, 09 Jul 2015 13:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:from:to:date:message-id:in-reply-to:references :user-agent:mime-version:content-type:content-transfer-encoding; bh=+Rf1ZexRTQVq+KoLURdcC9GP1StzUAr2LjJil2dvpYs=; b=Fl3dKzOhZ6l1BTcG50FDZRPFxlRupI3SvsEh/i7OusCJf0XLrlLLXVMK8KffVuOFnK NazIZu05nYkitC5wbu094OR8DIzn6e6Vmt9+R+2/e7i9UlccZn07PLoqruMZolzffswc kowmrkicWFT5JlX6WDHwkkwX9/WsBIQjKUGMcvy3HBX4PxfPM3JDGJlESAWd2SnJH20G Px+pY2uQ57wODcSkUkFZ2Jv8LLAo+1z3vwcmD4vkcgqLMsND20m1BAvoxVmhJzetONWy ZOeZEETzBgtLZVISyF4DV9LMwWUAzg+XwHbM9ScUzJoopW08jwV/Qhc5ci8bzRNUZC+B LHUw== X-Received: by 10.140.86.212 with SMTP id p78mr23623736qgd.49.1436474550311; Thu, 09 Jul 2015 13:42:30 -0700 (PDT) Received: from manet.1015granger.net ([2604:8800:100:81fc:82ee:73ff:fe43:d64f]) by smtp.gmail.com with ESMTPSA id h3sm4336235qgh.22.2015.07.09.13.42.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2015 13:42:29 -0700 (PDT) Subject: [PATCH v1 05/12] xprtrdma: Account for RPC/RDMA header size when deciding to inline From: Chuck Lever To: linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org Date: Thu, 09 Jul 2015 16:42:27 -0400 Message-ID: <20150709204227.26247.51111.stgit@manet.1015granger.net> In-Reply-To: <20150709203242.26247.4848.stgit@manet.1015granger.net> References: <20150709203242.26247.4848.stgit@manet.1015granger.net> User-Agent: StGit/0.17.1-3-g7d0f MIME-Version: 1.0 Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When marshaling RPC/RDMA requests, ensure the combined size of RPC/RDMA header and RPC header do not exceed the inline threshold. Endpoints typically reject RPC/RDMA messages that exceed the size of their receive buffers. Signed-off-by: Chuck Lever --- net/sunrpc/xprtrdma/rpc_rdma.c | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c index 84ea37d..8cf9402 100644 --- a/net/sunrpc/xprtrdma/rpc_rdma.c +++ b/net/sunrpc/xprtrdma/rpc_rdma.c @@ -71,6 +71,31 @@ static const char transfertypes[][12] = { }; #endif +/* The client can send a request inline as long as the RPCRDMA header + * plus the RPC call fit under the transport's inline limit. If the + * combined call message size exceeds that limit, the client must use + * the read chunk list for this operation. + */ +static bool rpcrdma_args_inline(struct rpc_rqst *rqst) +{ + unsigned int callsize = RPCRDMA_HDRLEN_MIN + rqst->rq_snd_buf.len; + + return callsize <= RPCRDMA_INLINE_WRITE_THRESHOLD(rqst); +} + +/* The client can’t know how large the actual reply will be. Thus it + * plans for the largest possible reply for that particular ULP + * operation. If the maximum combined reply message size exceeds that + * limit, the client must provide a write list or a reply chunk for + * this request. + */ +static bool rpcrdma_results_inline(struct rpc_rqst *rqst) +{ + unsigned int repsize = RPCRDMA_HDRLEN_MIN + rqst->rq_rcv_buf.buflen; + + return repsize <= RPCRDMA_INLINE_READ_THRESHOLD(rqst); +} + /* * Chunk assembly from upper layer xdr_buf. * @@ -418,7 +443,7 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) * a READ, then use write chunks to separate the file data * into pages; otherwise use reply chunks. */ - if (rqst->rq_rcv_buf.buflen <= RPCRDMA_INLINE_READ_THRESHOLD(rqst)) + if (rpcrdma_results_inline(rqst)) wtype = rpcrdma_noch; else if (rqst->rq_rcv_buf.page_len == 0) wtype = rpcrdma_replych; @@ -441,7 +466,7 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) * implies the op is a write. * TBD check NFSv4 setacl */ - if (rqst->rq_snd_buf.len <= RPCRDMA_INLINE_WRITE_THRESHOLD(rqst)) + if (rpcrdma_args_inline(rqst)) rtype = rpcrdma_noch; else if (rqst->rq_snd_buf.page_len == 0) rtype = rpcrdma_areadch;