Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp691055ybi; Fri, 31 May 2019 07:33:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqxZWMxX40COKJtHYG4SQ3g8ZRCFNS+QuubKyRM6592Mrb5ozpFdBTNLgnzV0aWHMfOdpu40 X-Received: by 2002:a17:902:6683:: with SMTP id e3mr9908225plk.291.1559313218259; Fri, 31 May 2019 07:33:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559313218; cv=none; d=google.com; s=arc-20160816; b=uT3NTBB2wHZBiSJTcVI81cGlGz5oj2ghc3eLOpL3GJBOluT93SGtZxEjDOl2bkdm0p b8iNrM5UTWYFeBIHhonuFgMIiTQzPBFFRnlvXwDdre405Jr+gZ3dcOXx7lO1HamSkKAM 7dGTlyLRWrpMFMX4qZJ598DmoasRijECJw2niWpYXj7Dmh4SpqZCz8r9UzIk6IZzoxWG KPPZ/tBjaPtq2Y2pCghrVyG1hpFVbYHfSnJIwhp1Y2nPFUQzGboPRuxohGf9wPR9PXjR u/fU66z/hb8qrg96n/v8EMpPeAyR31NvnfXkmEzp/dXTpfR0uCts4+ktAyLniifPlfLB mYEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject; bh=hB4OEybLUHC5zD+TTk8Rhx6lyxVZTy91HGyqTB0kEb8=; b=ts/R+RLCc37FGkqmg08T1mE9IVFZDUXR1oaenpX6JwYE6eCmff5SJE/E5jNQ4xD7a8 s5exWgYRXLardDgTgYMNUArRdzR5TkkOa0E5d8L/q7oOgqkVlnwXcop2haFz22plH1EM P6kz1W9jqqV9yf0R23aVNMSbDi8qUDEjjLgi3eH4oz70OE3Nzb8TFQguDcCJmVM182vt 9NRdWgMZAq4eWb+O2wz6/rPHRPbVrzbZHha7EV24lym8e81qAXVuxpAQiL6wlAyq/bQn nR+Xy6jVuAk+dvIoUv/IE8DB8sF1XmLD88jFcBsYeC108st9OlGUlviehPlmDBOBVQSc 4rZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w4si6276844plz.27.2019.05.31.07.33.13; Fri, 31 May 2019 07:33:38 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726797AbfEaOcD (ORCPT + 99 others); Fri, 31 May 2019 10:32:03 -0400 Received: from mga03.intel.com ([134.134.136.65]:36118 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726418AbfEaOcC (ORCPT ); Fri, 31 May 2019 10:32:02 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2019 07:32:01 -0700 X-ExtLoop1: 1 Received: from unknown (HELO [10.228.129.69]) ([10.228.129.69]) by fmsmga005.fm.intel.com with ESMTP; 31 May 2019 07:32:01 -0700 Subject: Re: [PATCH RFC 00/12] for-5.3 NFS/RDMA patches for review To: Chuck Lever , linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org References: <20190528181018.19012.61210.stgit@manet.1015granger.net> From: Dennis Dalessandro Message-ID: Date: Fri, 31 May 2019 10:32:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190528181018.19012.61210.stgit@manet.1015granger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On 5/28/2019 2:20 PM, Chuck Lever wrote: > This is a series of fixes and architectural changes that should > improve robustness and result in better scalability of NFS/RDMA. > I'm sure one or two of these could be broken down a little more, > comments welcome. > > The fundamental observation is that the RPC work queues are BOUND, > thus rescheduling work in the Receive completion handler to one of > these work queues just forces it to run later on the same CPU. So > try to do more work right in the Receive completion handler to > reduce context switch overhead. > > A secondary concern is that the average amount of wall-clock time > it takes to handle a single Receive completion caps the IOPS rate > (both per-xprt and per-NIC). In this patch series I've taken a few > steps to reduce that latency, and I'm looking into a few others. > > This series can be fetched from: > > git://git.linux-nfs.org/projects/cel/cel-2.6.git > > in topic branch "nfs-for-5.3". > > --- > > Chuck Lever (12): > xprtrdma: Fix use-after-free in rpcrdma_post_recvs > xprtrdma: Replace use of xdr_stream_pos in rpcrdma_marshal_req > xprtrdma: Fix occasional transport deadlock > xprtrdma: Remove the RPCRDMA_REQ_F_PENDING flag > xprtrdma: Remove fr_state > xprtrdma: Add mechanism to place MRs back on the free list > xprtrdma: Reduce context switching due to Local Invalidation > xprtrdma: Wake RPCs directly in rpcrdma_wc_send path > xprtrdma: Simplify rpcrdma_rep_create > xprtrdma: Streamline rpcrdma_post_recvs > xprtrdma: Refactor chunk encoding > xprtrdma: Remove rpcrdma_req::rl_buffer > > > include/trace/events/rpcrdma.h | 47 ++++-- > net/sunrpc/xprtrdma/frwr_ops.c | 330 ++++++++++++++++++++++++++------------- > net/sunrpc/xprtrdma/rpc_rdma.c | 146 +++++++---------- > net/sunrpc/xprtrdma/transport.c | 16 +- > net/sunrpc/xprtrdma/verbs.c | 115 ++++++-------- > net/sunrpc/xprtrdma/xprt_rdma.h | 43 +---- > 6 files changed, 384 insertions(+), 313 deletions(-) > For hfi1: Tested-by: Dennis Dalessandro