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 RFC 00/12] for-5.3 NFS/RDMA patches for review
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <ef371698-5b2f-40c2-8fcc-b3a3c57cd158@intel.com>
Date:   Fri, 31 May 2019 10:34:47 -0400
Cc:     linux-rdma@vger.kernel.org,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE9BE961-6555-46FF-A9ED-601468D5DBD7@oracle.com>
References: <20190528181018.19012.61210.stgit@manet.1015granger.net>
 <ef371698-5b2f-40c2-8fcc-b3a3c57cd158@intel.com>
To:     Dennis Dalessandro <dennis.dalessandro@intel.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On May 31, 2019, at 10:32 AM, Dennis Dalessandro =
<dennis.dalessandro@intel.com> wrote:
>=20
> 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(-)
>=20
> For hfi1:
> Tested-by: Dennis Dalessandro <dennis.dalessandro@intel.com>

Thanks!

--
Chuck Lever