NfsRdmaClient/Home

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
(Add link for ffsb)
 
(14 intermediate revisions not shown)
Line 3: Line 3:
=== Goals ===
=== Goals ===
-
Provide maintenance resources for NFS/RDMA and RPC/RDMA client-side code in the Linux kernel to support continuous testing of upstream kernels and identify engineering resources for bug fixes and enhancements. We are also working to identify resources for supporting server-side code.
+
Provide maintenance for NFS/RDMA and RPC/RDMA client-side code in the Linux kernel. Support continuous testing of NFS/RDMA  feature in upstream Linux kernels. Provide enhancements (see below). Identify resources for supporting server-side code.
=== Bug tracking ===
=== Bug tracking ===
Upstream bug tracking is [http://bugzilla.kernel.org/ here].
Upstream bug tracking is [http://bugzilla.kernel.org/ here].
-
 
-
=== Git tree ===
 
-
 
-
See [http://git.linux-nfs.org/?p=cel/cel-2.6.git;a=summary git.linux-nfs.org].
 
=== Feature planning ===
=== Feature planning ===
Our [https://www.pivotaltracker.com/projects/958376 Pivotal Tracking project] lists individual work items and defines several long-term arcs. At a high level, these include:
Our [https://www.pivotaltracker.com/projects/958376 Pivotal Tracking project] lists individual work items and defines several long-term arcs. At a high level, these include:
-
* Broad support for a variety of InfiniBand hardware
+
* Broad support for a variety of RDMA-capable hardware
-
* Performance and scalability enhancements that require nontrivial implementation effort
+
* Performance and scalability enhancements
* Support for NFSv4.1
* Support for NFSv4.1
-
* Observability enhancements to enable distributor support teams and customers to diagnose and address problems
+
* Observability features that enable distributor support teams and customers to diagnose and address problems
 +
 
 +
=== Developer tools ===
 +
 
 +
For anyone working directly on Linux NFS/RDMA or RPC/RDMA, please consider the following tools for validating your work.
 +
* cthon04: git://git.linux-nfs.org/projects/steved/cthon04.git
 +
* xfstests: git://oss.sgi.com/xfs/cmds/xfstests
 +
* nfs-o-meter: git://git.linux-nfs.org/projects/dros/nfsometer.git
 +
* [http://codemonkey.org.uk/projects/fsx/ fsx]
 +
* [http://www.iozone.org/ IOzone]
 +
* [http://freecode.com/projects/fio fio]
 +
* Multi-process Linux kernel builds
 +
* [http://downloads.sourceforge.net/project/ffsb/ffsb/ffsb-6.0-rc2/ffsb-6.0-rc2.tar.bz2 ffsb]
 +
 
 +
Typically, for testing, the NFS/RDMA server exports a tmpfs or ram disk-based local FS to drive the transport fast enough.
 +
 
 +
==== Asking for help ====
 +
 
 +
You can find Linux NFS developers at linux-nfs@vger.kernel.org, or in the linux-nfs chatroom at oftc.net.
 +
 
 +
=== Submitting patches ===
 +
 
 +
Clone the upstream Linux kernel with:
 +
 
 +
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
 +
 
 +
General advice for preparing upstream kernel or nfs-utils patches: see [https://www.kernel.org/doc/Documentation/SubmittingPatches SubmittingPatches].
 +
 
 +
It is strongly recommended that patches be compile-tested, tested with sparse, and run by scripts/checkpatch.pl before submission. Patches should be tested with the tools above before submission, though that's not needed if you are posting only for review.
 +
 
 +
==== Review ====
 +
 
 +
Review is done via e-mail. In the kernel source tree, see Documentation/email-clients.txt for important advice on how to use e-mail to submit patches.
 +
 
 +
Label your patches "[RFC ... ]" or "untested" "DO NOT APPLY" or "for review only" so maintainers know the patch is for review and may not be broadly tested yet.
 +
 
 +
Submit patches to linux-nfs@vger.kernel.org and linux-rdma@vger.kernel.org for review.
 +
 
 +
If you have reviewed a posted patch, reply with a "Reviewed-by:". If you've tested it, reply with a "Tested-by:"
 +
 
 +
==== Merge request ====
 +
 
 +
When the community feels a client-side patch is ready to be merged, submit the patches again (without "for review" disclaimers) to linux-nfs@vger.kernel.org and linux-rdma@vger.kernel.org, and cc: Anna.Schumaker@netapp.com. Anna will collect ready patches for Trond to merge upstream.
-
Lower priority items include notably:
+
We are still developing a mechanism for requesting server-side fixes be merged.
-
* Maintenance of the Linux NFS/RDMA server implementation
+
-
* Support for iWARP and RoCE
+
-
* Support for pNFS over RDMA
+
=== Engineering Notes ===
=== Engineering Notes ===
* [[NfsRdmaClient/MemRegModes|Simplifying memory registration modes]]
* [[NfsRdmaClient/MemRegModes|Simplifying memory registration modes]]

Latest revision as of 20:54, 14 October 2014

Contents

Support for Linux NFS/RDMA Client upstream

Goals

Provide maintenance for NFS/RDMA and RPC/RDMA client-side code in the Linux kernel. Support continuous testing of NFS/RDMA feature in upstream Linux kernels. Provide enhancements (see below). Identify resources for supporting server-side code.

Bug tracking

Upstream bug tracking is here.

Feature planning

Our Pivotal Tracking project lists individual work items and defines several long-term arcs. At a high level, these include:

  • Broad support for a variety of RDMA-capable hardware
  • Performance and scalability enhancements
  • Support for NFSv4.1
  • Observability features that enable distributor support teams and customers to diagnose and address problems

Developer tools

For anyone working directly on Linux NFS/RDMA or RPC/RDMA, please consider the following tools for validating your work.

  • cthon04: git://git.linux-nfs.org/projects/steved/cthon04.git
  • xfstests: git://oss.sgi.com/xfs/cmds/xfstests
  • nfs-o-meter: git://git.linux-nfs.org/projects/dros/nfsometer.git
  • fsx
  • IOzone
  • fio
  • Multi-process Linux kernel builds
  • ffsb

Typically, for testing, the NFS/RDMA server exports a tmpfs or ram disk-based local FS to drive the transport fast enough.

Asking for help

You can find Linux NFS developers at linux-nfs@vger.kernel.org, or in the linux-nfs chatroom at oftc.net.

Submitting patches

Clone the upstream Linux kernel with:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

General advice for preparing upstream kernel or nfs-utils patches: see SubmittingPatches.

It is strongly recommended that patches be compile-tested, tested with sparse, and run by scripts/checkpatch.pl before submission. Patches should be tested with the tools above before submission, though that's not needed if you are posting only for review.

Review

Review is done via e-mail. In the kernel source tree, see Documentation/email-clients.txt for important advice on how to use e-mail to submit patches.

Label your patches "[RFC ... ]" or "untested" "DO NOT APPLY" or "for review only" so maintainers know the patch is for review and may not be broadly tested yet.

Submit patches to linux-nfs@vger.kernel.org and linux-rdma@vger.kernel.org for review.

If you have reviewed a posted patch, reply with a "Reviewed-by:". If you've tested it, reply with a "Tested-by:"

Merge request

When the community feels a client-side patch is ready to be merged, submit the patches again (without "for review" disclaimers) to linux-nfs@vger.kernel.org and linux-rdma@vger.kernel.org, and cc: Anna.Schumaker@netapp.com. Anna will collect ready patches for Trond to merge upstream.

We are still developing a mechanism for requesting server-side fixes be merged.

Engineering Notes

Personal tools