From: Chuck Lever <chuck.lever@oracle.com>
To: linux-rdma <linux-rdma@vger.kernel.org>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: [PATCH v3 00/21] NFS/RDMA client patches for 3.17
Date: Tue, 15 Jul 2014 10:24:16 -0400 [thread overview]
Message-ID: <59034BAD-306F-462F-A274-3EB06C0CBE47@oracle.com> (raw)
The main purpose of this series is to address connection drop
recovery issues by fixing FRMR re-use to make it less likely the
client will deadlock due to a memory management operation error.
Some clean-ups and other fixes are present as well.
See topic branch nfs-rdma-for-3.17 in
git://git.linux-nfs.org/projects/cel/cel-2.6.git
I tested with NFSv3 and NFSv4 on all three supported memory
registration modes. Used cthon04, iozone, and dbench with both
Solaris and Linux NFS/RDMA servers. Used xfstests with Linux.
v3:
Only two substantive changes:
- Patch 08/21 now uses generic IB helpers for managing FRMR
rkeys
- Add Tested-by: from Steve Wise
v2:
Many patches from v1 have been written or replaced.
The MW ref counting approach in v1 is abandoned. Instead, I've
eliminated signaling FAST_REG_MR and LOCAL_INV, and added
appropriate recovery mechanisms after a transport reconnect that
should prevent rkey dis-synchrony entirely.
A couple of optimizations have been added, including:
- Allocating each MW separately rather than carving each out of a
large piece of contiguous memory
- Now that the receive CQ upcall handler dequeues a bundle of CQEs
at once, fire off the reply handler tasklet just once per upcall
to reduce context switches and how often hard IRQs are disabled
Jury is still out on the latter.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
next reply other threads:[~2014-07-15 14:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 14:24 Chuck Lever [this message]
2014-07-16 15:48 ` [PATCH v3 00/21] NFS/RDMA client patches for 3.17 Shirley Ma
2014-07-16 17:57 ` Chuck Lever
2014-07-16 18:22 ` Shirley Ma
2014-07-17 5:06 ` Devesh Sharma
2014-07-17 14:12 ` Devesh Sharma
2014-07-17 14:16 ` Chuck Lever
2014-07-17 14:21 ` Devesh Sharma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59034BAD-306F-462F-A274-3EB06C0CBE47@oracle.com \
--to=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox