From patchwork Mon Aug 3 17:04:08 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuck Lever III X-Patchwork-Id: 6931471 Return-Path: X-Original-To: patchwork-linux-rdma@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 4EC2B9F402 for ; Mon, 3 Aug 2015 17:04:22 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D252E2039E for ; Mon, 3 Aug 2015 17:04:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9A95E20641 for ; Mon, 3 Aug 2015 17:04:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754732AbbHCREN (ORCPT ); Mon, 3 Aug 2015 13:04:13 -0400 Received: from mail-qg0-f51.google.com ([209.85.192.51]:34638 "EHLO mail-qg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754753AbbHCREL (ORCPT ); Mon, 3 Aug 2015 13:04:11 -0400 Received: by qgeu79 with SMTP id u79so93212800qge.1; Mon, 03 Aug 2015 10:04:10 -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=7JQo/OkWX9/8UqC8EEShenfJgU34XHlsv8x5cU3sF3E=; b=GHnT+gHwqi7FWanP4JKRErqh6ftV7Bm7lCt7YSMbhvzMmHca/qalzQstv4bb+vlDOT CjCfkViCb9Y9iurYR5cVhFqD6cS5A3npA5Xc+VA9s9bZlykeE1xl9xz0HoHIAiclVxnL UATMAKlXkuDfzjk5OAMWgLyv8h4wE+A18XqVfls8e+9H2iQBXncsKCDv8mu0KbNdAqL2 F7qH9pJD35iN+PNLwae0Fh2dgWl7WKGLT3BNHIVOTJwRiBuifAB5QPCUTVLXt/Bo2C09 HlvWQvwEbIvqJkQxthVY57ag7ANcgulLK4FtZjEQ8oOW3voM7aB8+qFpXblSxP5Yc2Il 8Z1w== X-Received: by 10.140.93.43 with SMTP id c40mr26402974qge.54.1438621450365; Mon, 03 Aug 2015 10:04:10 -0700 (PDT) Received: from manet.1015granger.net ([2604:8800:100:81fc:82ee:73ff:fe43:d64f]) by smtp.gmail.com with ESMTPSA id 2sm7098272qhw.10.2015.08.03.10.04.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 10:04:09 -0700 (PDT) Subject: [PATCH v4 10/16] xprtrdma: Don't provide a reply chunk when expecting a short reply From: Chuck Lever To: linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org Date: Mon, 03 Aug 2015 13:04:08 -0400 Message-ID: <20150803170408.9115.58172.stgit@manet.1015granger.net> In-Reply-To: <20150803165807.9115.23842.stgit@manet.1015granger.net> References: <20150803165807.9115.23842.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.0 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 Currently Linux always offers a reply chunk, even when the reply can be sent inline (ie. is smaller than 1KB). On the client, registering a memory region can be expensive. A server may choose not to use the reply chunk, wasting the cost of the registration. This is a change only for RPC replies smaller than 1KB which the server constructs in the RPC reply send buffer. Because the elements of the reply must be XDR encoded, a copy-free data transfer has no benefit in this case. Signed-off-by: Chuck Lever Reviewed-by: Sagi Grimberg Tested-by: Devesh Sharma --- net/sunrpc/xprtrdma/rpc_rdma.c | 13 +------------ 1 file changed, 1 insertion(+), 12 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 e7cf976..62150ae 100644 --- a/net/sunrpc/xprtrdma/rpc_rdma.c +++ b/net/sunrpc/xprtrdma/rpc_rdma.c @@ -420,7 +420,7 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) * * o Read ops return data as write chunk(s), header as inline. * o If the expected result is under the inline threshold, all ops - * return as inline (but see later). + * return as inline. * o Large non-read ops return as a single reply chunk. */ if (rqst->rq_rcv_buf.flags & XDRBUF_READ) @@ -476,17 +476,6 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) headerp->rm_body.rm_nochunks.rm_empty[2] = xdr_zero; /* new length after pullup */ rpclen = rqst->rq_svec[0].iov_len; - /* Currently we try to not actually use read inline. - * Reply chunks have the desirable property that - * they land, packed, directly in the target buffers - * without headers, so they require no fixup. The - * additional RDMA Write op sends the same amount - * of data, streams on-the-wire and adds no overhead - * on receive. Therefore, we request a reply chunk - * for non-writes wherever feasible and efficient. - */ - if (wtype == rpcrdma_noch) - wtype = rpcrdma_replych; } if (rtype != rpcrdma_noch) {