NfsRdmaClient/Home

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
(Submitting patches)
(Add link for ffsb)
 
(5 intermediate revisions not shown)
Line 22: Line 22:
* cthon04: git://git.linux-nfs.org/projects/steved/cthon04.git
* cthon04: git://git.linux-nfs.org/projects/steved/cthon04.git
* xfstests: git://oss.sgi.com/xfs/cmds/xfstests
* 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://codemonkey.org.uk/projects/fsx/ fsx]
* [http://www.iozone.org/ IOzone]
* [http://www.iozone.org/ IOzone]
* [http://freecode.com/projects/fio fio]
* [http://freecode.com/projects/fio fio]
* Multi-process Linux kernel builds
* 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.
Typically, for testing, the NFS/RDMA server exports a tmpfs or ram disk-based local FS to drive the transport fast enough.
Line 41: Line 43:
General advice for preparing upstream kernel or nfs-utils patches: see [https://www.kernel.org/doc/Documentation/SubmittingPatches SubmittingPatches].
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. Be sure to label your patch "untested" or "for review only" in that case.
+
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.
-
Submit patches to linux-nfs@vger.kernel.org for review. For RPC/RDMA patches, consider courtesy-copying linux-rdma@vger.kernel.org.
+
==== 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 ===
=== 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