NfsRdmaClient/Home

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
m (Submitting patches)
(Add link for ffsb)
 
(8 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.
 +
 +
==== 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 ===
=== Submitting patches ===
Line 37: 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].
-
Submit patches to linux-nfs@vger.kernel.org. For RPC/RDMA, consider courtesy-copying linux-rdma@vger.kernel.org.
+
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 ===
=== 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