update rdma-plumbing Documentation

update rdma-plumbing Documentation

[Christoph Hellwig]

Get rid of the per-subproject README files and instead improve the top-level
README.md as well as adding a few new files for more details to Documentation/

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/9] add reporting bugs and submitting patches sections to README.md

[Christoph Hellwig]

Based on the wording from the libibverbs and srp_daemon README files.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 README.md | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/README.md b/README.md
index 26f44c1..4cf1eed 100644
--- a/README.md
+++ b/README.md
@@ -95,3 +95,31 @@ $ install -m755 ninja /usr/local/bin/ninja
 ```
 
 Use the 'cmake3' program in place of `cmake` in the above instructions.
+
+# Reporting bugs
+
+Bugs should be reported to the <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> mailing list
+In your bug report, please include:
+
+ * Information about your system:
+   - Linux distribution and version
+   - Linux kernel and version
+   - InfiniBand hardware and firmware version
+   - ... any other relevant information
+
+ * How to reproduce the bug.
+
+ * If the bug is a crash, the exact output printed out when the crash
+   occurred, including any kernel messages produced.
+
+# Submitting patches
+
+Patches should also be submitted to the <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
+mailing list.  Please use unified diff form (the -u option to GNU diff),
+and include a good description of what your patch does and why it should
+be applied.  If your patch fixes a bug, please make sure to describe the
+bug and how your fix works.
+
+Make sure that your contribution can be licensed under the same
+license as the original code you are patching, and that you have all
+necessary permissions to release your work.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/9] remove empty documentation files

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 libibcm/INSTALL   | 0
 libibcm/NEWS      | 0
 librdmacm/INSTALL | 0
 librdmacm/NEWS    | 0
 4 files changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 libibcm/INSTALL
 delete mode 100644 libibcm/NEWS
 delete mode 100644 librdmacm/INSTALL
 delete mode 100644 librdmacm/NEWS

diff --git a/libibcm/INSTALL b/libibcm/INSTALL
deleted file mode 100644
index e69de29..0000000
diff --git a/libibcm/NEWS b/libibcm/NEWS
deleted file mode 100644
index e69de29..0000000
diff --git a/librdmacm/INSTALL b/librdmacm/INSTALL
deleted file mode 100644
index e69de29..0000000
diff --git a/librdmacm/NEWS b/librdmacm/NEWS
deleted file mode 100644
index e69de29..0000000
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/9] remove README files in the provider directories

[Christoph Hellwig]

These were all almost the same and add no real value over the top-level
README.md file.  The only lost information is the exact names of supported
cards for some providers, but that already is information duplicated from
the kernel drivers and bound to get out of sync anyway.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 providers/cxgb3/README      | 19 ---------------
 providers/cxgb4/README      | 19 ---------------
 providers/hfi1verbs/README  | 23 ------------------
 providers/ipathverbs/README | 24 ------------------
 providers/mlx4/README       | 58 --------------------------------------------
 providers/mlx5/README       | 14 -----------
 providers/mthca/README      | 59 ---------------------------------------------
 providers/ocrdma/README     | 19 ---------------
 8 files changed, 235 deletions(-)
 delete mode 100644 providers/cxgb3/README
 delete mode 100644 providers/cxgb4/README
 delete mode 100644 providers/hfi1verbs/README
 delete mode 100644 providers/ipathverbs/README
 delete mode 100644 providers/mlx4/README
 delete mode 100644 providers/mlx5/README
 delete mode 100644 providers/mthca/README
 delete mode 100644 providers/ocrdma/README

diff --git a/providers/cxgb3/README b/providers/cxgb3/README
deleted file mode 100644
index 9d0dd49..0000000
--- a/providers/cxgb3/README
+++ /dev/null
@@ -1,19 +0,0 @@
-Introduction
-============
-
-libcxgb3 is a userspace driver for the Chelsio T3 iWARP RNIC.  It works
-as a plug-in module for libibverbs that allows programs to use Chelsio
-RNICs directly from userspace.  See the libibverbs package for more
-information.
-
-Using libcxgb3
-===================
-
-libcxgb3 will be loaded and used automatically by programs linked with
-libibverbs.  The iw_cxgb3 kernel module must be loaded for Chelsio RNIC
-devices to be detected and used.
-
-Supported Hardware
-==================
-
-libcxgb3 supports the Chelsio T3 family of adapters.
diff --git a/providers/cxgb4/README b/providers/cxgb4/README
deleted file mode 100644
index a4ee33a..0000000
--- a/providers/cxgb4/README
+++ /dev/null
@@ -1,19 +0,0 @@
-Introduction
-============
-
-libcxgb4 is a userspace driver for the Chelsio T4/T5 iWARP RNICs.  It works
-as a plug-in module for libibverbs that allows programs to use Chelsio
-RNICs directly from userspace.  See the libibverbs package for more
-information.
-
-Using libcxgb4
-===================
-
-libcxgb4 will be loaded and used automatically by programs linked with
-libibverbs.  The iw_cxgb4 kernel module must be loaded for Chelsio RNIC
-devices to be detected and used.
-
-Supported Hardware
-==================
-
-libcxgb4 supports the Chelsio T4/T5 family of adapters.
diff --git a/providers/hfi1verbs/README b/providers/hfi1verbs/README
deleted file mode 100644
index 9b6f812..0000000
--- a/providers/hfi1verbs/README
+++ /dev/null
@@ -1,23 +0,0 @@
-Introduction
-============
-
-libhfiverbs is a userspace driver for the Intel Host Fabric
-interface.
-
-It works as a plug-in module for libibverbs that allows programs to use
-Intel HFI's directly from userspace.  See the libibverbs package for
-more information.
-
-Using libhfiverbs
-===================
-
-libhfiverbs will be loaded and used automatically by programs linked
-with libibverbs.  The hfi kernel module must be loaded for Intel
-fabric devices to be detected and used.
-
-Supported Hardware
-==================
-
-libhfiverbs currently supports the following Intel Host fabric
-interfaces:
-	TBR
diff --git a/providers/ipathverbs/README b/providers/ipathverbs/README
deleted file mode 100644
index a05997f..0000000
--- a/providers/ipathverbs/README
+++ /dev/null
@@ -1,24 +0,0 @@
-Introduction
-============
-
-libipathverbs is a userspace driver for the Intel InfiniBand HCAs.
-It works as a plug-in module for libibverbs that allows programs to use
-Intel HCAs directly from userspace.  See the libibverbs package for
-more information.
-
-Using libipathverbs
-===================
-
-libipathverbs will be loaded and used automatically by programs linked
-with libibverbs.  The ib_ipath kernel module must be loaded for Intel
-HCA devices to be detected and used.
-
-Supported Hardware
-==================
-
-libipathverbs currently supports the following Intel HCAs:
-
-	InfiniPath QLE7140 PCIe Adapter
-	InfiniPath QMI7140 PCIe Adapter
-	InfiniPath QHT7040 HyperTransport Adapter
-	InfiniPath QHT7140 HyperTransport Adapter
diff --git a/providers/mlx4/README b/providers/mlx4/README
deleted file mode 100644
index 5c027ef..0000000
--- a/providers/mlx4/README
+++ /dev/null
@@ -1,58 +0,0 @@
-Introduction
-============
-
-libmlx4 is a userspace driver for Mellanox ConnectX InfiniBand HCAs.
-It is a plug-in module for libibverbs that allows programs to use
-Mellanox hardware directly from userspace.  See the libibverbs package
-for more information.
-
-Using libmlx4
-==============
-
-libmlx4 will be loaded and used automatically by programs linked with
-libibverbs.  The mlx4_ib kernel module must be loaded for HCA devices
-to be detected and used.
-
-Supported Hardware
-==================
-
-libmlx4 currently supports HCAs based on the following Mellanox chip:
-
-    MT25408 ConnectX (PCI Express)
-
-These HCAs use the mlx4_ib kernel driver.  Support for other Mellanox
-HCAs, which use the ib_mthca kernel driver, is provided by the
-libmthca userspace driver.
-
-Valgrind Support
-================
-
-When running applications that use libibverbs under the Valgrind
-memory-checking debugger, Valgrind will falsely report "read from
-uninitialized" for memory that was initialized by the kernel drivers
-or HCA hardware.  Specifically, Valgrind cannot see when kernel
-drivers or HCA hardware write to userspace memory, so when the process
-reads from that memory, Valgrind incorrectly assumes that the memory
-contents are uninitialized, and therefore raises a warning.
-
-libmlx4 can be built with specific support for the Valgrind
-memory-checking debugger by specifying the --with-valgrind command
-line argument to configure.  This flag enables code in libibverbs to
-tell Valgrind "this memory may look uninitialized, but it's really
-OK," which therefore suppresses the incorrect "read from
-uninitialized" warnings.  This code adds trivial overhead to the
-critical performance path, so it is disabled by default.  The intent
-is that production users can use a "normal" build of libmlx4 and
-developers can use the "valgrind debug" build by simply switching
-their OPENIB_DRIVER_PATH environment variables.
-
-Libmlx4 needs some header files from Valgrind in order to compile this
-support; it is important to use the header files from the same version
-of Valgrind that will be used at run time.  You may need to specify
-the directory where Valgrind's header files are installed as an
-argument to --with-valgrind.  For example
-
-	./configure --with-valgrind=/opt/valgrind
-
-will make the libmlx4 build look for valgrind headers in
-/opt/valgrind/include
diff --git a/providers/mlx5/README b/providers/mlx5/README
deleted file mode 100644
index 6c713e6..0000000
--- a/providers/mlx5/README
+++ /dev/null
@@ -1,14 +0,0 @@
-Introduction
-============
-
-libmlx5 is a userspace driver for Mellanox ConnectX InfiniBand HCAs.
-It is a plug-in module for libibverbs that allows programs to use
-Mellanox hardware directly from userspace.  See the libibverbs package
-for more information.
-
-Using libmlx5
-==============
-
-libmlx5 will be loaded and used automatically by programs linked with
-libibverbs.  The mlx5_ib kernel module must be loaded for HCA devices
-to be detected and used.
diff --git a/providers/mthca/README b/providers/mthca/README
deleted file mode 100644
index 88636f8..0000000
--- a/providers/mthca/README
+++ /dev/null
@@ -1,59 +0,0 @@
-Introduction
-============
-
-libmthca is a userspace driver for Mellanox InfiniBand HCAs.  It works
-as a plug-in module for libibverbs that allows programs to use
-Mellanox hardware directly from userspace.  See the libibverbs package
-for more information.
-
-Using libmthca
-==============
-
-libmthca will be loaded and used automatically by programs linked with
-libibverbs.  The ib_mthca kernel module must be loaded for HCA devices
-to be detected and used.
-
-Supported Hardware
-==================
-
-libmthca currently supports HCAs based on the following Mellanox chips:
-
-    MT23108 InfiniHost (PCI-X)
-    MT25208 InfiniHost III Ex (PCI Express)
-    MT25204 InfiniHost III Lx (PCI Express)
-
-Both non-DDR and DDR HCAs are supported, and the MT25208 is supported
-with both MT23108-compatible and native MemFree firmware.
-
-Valgrind Support
-================
-
-When running applications that use libibverbs under the Valgrind
-memory-checking debugger, Valgrind will falsely report "read from
-uninitialized" for memory that was initialized by the kernel drivers
-or HCA hardware.  Specifically, Valgrind cannot see when kernel
-drivers or HCA hardware write to userspace memory, so when the process
-reads from that memory, Valgrind incorrectly assumes that the memory
-contents are uninitialized, and therefore raises a warning.
-
-libmthca can be built with specific support for the Valgrind
-memory-checking debugger by specifying the --with-valgrind command
-line argument to configure.  This flag enables code in libibverbs to
-tell Valgrind "this memory may look uninitialized, but it's really
-OK," which therefore suppresses the incorrect "read from
-uninitialized" warnings.  This code adds trivial overhead to the
-critical performance path, so it is disabled by default.  The intent
-is that production users can use a "normal" build of libmthca and
-developers can use the "valgrind debug" build by simply switching
-their OPENIB_DRIVER_PATH environment variables.
-
-Libmthca needs some header files from Valgrind in order to compile
-this support; it is important to use the header files from the same
-version of Valgrind that will be used at run time.  You may need to
-specify the directory where Valgrind's header files are installed as
-an argument to --with-valgrind.  For example
-
-	./configure --with-valgrind=/opt/valgrind
-
-will make the libmthca build look for valgrind headers in
-/opt/valgrind/include
diff --git a/providers/ocrdma/README b/providers/ocrdma/README
deleted file mode 100644
index 6ae30fe..0000000
--- a/providers/ocrdma/README
+++ /dev/null
@@ -1,19 +0,0 @@
-Introduction
-============
-
-libocrdma is a userspace driver for Emulex OneConnect RDMA Adapters.
-It is a plug-in module for libibverbs that allows programs to use
-Emulex RDMA hardware directly from userspace. See the libibverbs
-package for more information.
-
-Using libocrdma
-===============
-
-libocrdma will be loaded and used automatically by programs linked
-with libibverbs. The ocrdma kernel modules must be loaded for RDMA
-devices to be detected and used.
-
-Supported Hardware
-==================
-
-libocrdma supports all RDMA capable  Emulex adapters.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/9] move rxe documentation to Documentation/

[Christoph Hellwig]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=a, Size: 4278 bytes --]

Very little of the rxe RADME.md is relevant with the kernel driver upstream,
and the userspace provider part of this repository.  Move the remaining bits
to Documentation/rxe.md and delete the rest.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 Documentation/rxe.md    | 19 +++++++++++++++
 providers/rxe/README.md | 63 -------------------------------------------------
 2 files changed, 19 insertions(+), 63 deletions(-)
 create mode 100644 Documentation/rxe.md
 delete mode 100644 providers/rxe/README.md

diff --git a/Documentation/rxe.md b/Documentation/rxe.md
new file mode 100644
index 0000000..ec5ba58
--- /dev/null
+++ b/Documentation/rxe.md
@@ -0,0 +1,19 @@
+# Configure Soft-RoCE (RXE):
+
+Load rdma_rxe kernel module using the rxe_cfg script included in the librxe RPM:
+
+rxe_cfg start (this might require sudo or root privileges)
+
+Create RXE device over network interface (e.g. eth0):
+
+rxe_cfg add eth0
+
+Use the status command to display the current configuration:
+rxe_cfg status
+
+If configured successfully, you should see output similar to the following:
+    Name  Link  Driver   Speed  NMTU  IPv4_addr  RDEV  RMTU         
+    eth0  yes   mlx4_en                          rxe0  1024  (3) 
+ 
+If you are using a Mellanox HCA: Need to make sure that the mlx4_ib kernel module is not loaded (modprobe –rv mlx4_ib) in the soft-RoCE machine.
+Now you have an Infiniband device called “rxe0” that can be used to run any RoCE app.
diff --git a/providers/rxe/README.md b/providers/rxe/README.md
deleted file mode 100644
index 743edd1..0000000
--- a/providers/rxe/README.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# librxe-dev
-Development repository for RXE user space code.
-Soft RDMA over Ethernet (RoCE) Driver
-
-Source
-
-Kernel Space Driver
-
-This repository contains a full kernel source tree, with the RoCE driver code located in the directory drivers/infiniband/hw/rxe.
-
-Github: https://github.com/SoftRoCE/rxe-dev.git 
-Active Branch: master-next
-User Space Library
-
-Github: https://github.com/SoftRoCE/librxe-dev.git (this repository)
-Current Version: librxe-1.0.0
-Build Instructions
-
-Compile and install kernel:
-
-Clone kernel git:
-git clone https://github.com/SoftRoCE/rxe-dev.git
-Compile kernel:
-Enter the source directory cd rxe-dev
-cp /boot/config-$(uname –r) .config
-make menuconfig
-Need to enable “Software RDMA over Ethernet (RoCE) driver” in category "Device Drivers -> Infiniband"
-Need to enable CONFIG_INFINIBAND_ADDR_TRANS=y and CONFIG_INFINIBAND_ADDR_TRANS_CONFIGFS=y in new config file .config
-make –j 32
-make modules_install
-make install
-Verify that the new kernel entry is added (e.g. to grub); if not, need to add it manually.
-Boot with new kernel.
-Install user space library (librxe):
-
-Install the following package (example shown using RedHat):
-yum install perl-Switch (name might vary according to distribution)
-Make sure that the following upstream user space libraries are installed:
-libibverbs
-libibverbs-devel
-libibverbs-utils
-librdmacm
-librdmacm-devel
-librdmacm-utils
-Compile and install user space library librxe:
-git clone https://github.com/SoftRoCE/librxe-dev.git
-cd librxe-dev
-./configure --libdir=/usr/lib64/ --prefix=
-make
-make install
-Configure Soft-RoCE (RXE):
-
-Load rdma_rxe kernel module using the rxe_cfg script included in the librxe RPM:
-rxe_cfg start (this might require sudo or root privileges)
-Create RXE device over network interface (e.g. eth0):
-rxe_cfg add eth0
-Use the status command to display the current configuration:
-rxe_cfg status
-If configured successfully, you should see output similar to the following:
-    Name  Link  Driver   Speed  NMTU  IPv4_addr  RDEV  RMTU         
-    eth0  yes   mlx4_en                          rxe0  1024  (3) 
-If you are using a Mellanox HCA: Need to make sure that the mlx4_ib kernel module is not loaded (modprobe –rv mlx4_ib) in the soft-RoCE machine.
-Now you have an Infiniband device called “rxe0” that can be used to run any RoCE app.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/9] move libibverbs documentation to Documentation/

[Christoph Hellwig]

And drop bits that are outdated or replaced by top-level Documentation.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 Documentation/libibverbs.md |  58 ++++++++++++++++
 libibverbs/README           | 164 --------------------------------------------
 2 files changed, 58 insertions(+), 164 deletions(-)
 create mode 100644 Documentation/libibverbs.md
 delete mode 100644 libibverbs/README

diff --git a/Documentation/libibverbs.md b/Documentation/libibverbs.md
new file mode 100644
index 0000000..cbe076e
--- /dev/null
+++ b/Documentation/libibverbs.md
@@ -0,0 +1,58 @@
+# Introduction
+
+libibverbs is a library that allows programs to use RDMA "verbs" for
+direct access to RDMA (currently InfiniBand and iWARP) hardware from
+userspace.  For more information on RDMA verbs, see the InfiniBand
+Architecture Specification vol. 1, especially chapter 11, and the RDMA
+Consortium's RDMA Protocol Verbs Specification.
+
+# Using libibverbs
+
+### Device nodes
+
+The verbs library expects special character device files named
+/dev/infiniband/uverbsN to be created.  When you load the kernel
+modules, including both the low-level driver for your IB hardware as
+well as the ib_uverbs module, you should see one or more uverbsN
+entries in /sys/class/infiniband_verbs in addition to the
+/dev/infiniband/uverbsN character device files.
+
+To create the appropriate character device files automatically with
+udev, a rule like
+
+    KERNEL="uverbs*", NAME="infiniband/%k"
+
+can be used.  This will create device nodes named
+
+    /dev/infiniband/uverbs0
+
+and so on.  Since the RDMA userspace verbs should be safe for use by
+non-privileged users, you may want to add an appropriate MODE or GROUP
+to your udev rule.
+
+### Permissions
+
+To use IB verbs from userspace, a process must be able to access the
+appropriate /dev/infiniband/uverbsN special device file.  You can
+check the permissions on this file with the command
+
+	ls -l /dev/infiniband/uverbs*
+
+Make sure that the permissions on these files are such that the
+user/group that your verbs program runs as can access the device file.
+
+To use IB verbs from userspace, a process must also have permission to
+tell the kernel to lock sufficient memory for all of your registered
+memory regions as well as the memory used internally by IB resources
+such as queue pairs (QPs) and completion queues (CQs).  To check your
+resource limits, use the command
+
+	ulimit -l
+
+(or "limit memorylocked" for csh-like shells).
+
+If you see a small number such as 32 (the units are KB) then you will
+need to increase this limit.  This is usually done for ordinary users
+via the file /etc/security/limits.conf.  More configuration may be
+necessary if you are logging in via OpenSSH and your sshd is
+configured to use privilege separation.
diff --git a/libibverbs/README b/libibverbs/README
deleted file mode 100644
index 848eb05..0000000
--- a/libibverbs/README
+++ /dev/null
@@ -1,164 +0,0 @@
-Introduction
-============
-
-libibverbs is a library that allows programs to use RDMA "verbs" for
-direct access to RDMA (currently InfiniBand and iWARP) hardware from
-userspace.  For more information on RDMA verbs, see the InfiniBand
-Architecture Specification vol. 1, especially chapter 11, and the RDMA
-Consortium's RDMA Protocol Verbs Specification.
-
-Using libibverbs
-================
-
-Device nodes
-------------
-
-The verbs library expects special character device files named
-/dev/infiniband/uverbsN to be created.  When you load the kernel
-modules, including both the low-level driver for your IB hardware as
-well as the ib_uverbs module, you should see one or more uverbsN
-entries in /sys/class/infiniband_verbs in addition to the
-/dev/infiniband/uverbsN character device files.
-
-To create the appropriate character device files automatically with
-udev, a rule like
-
-    KERNEL="uverbs*", NAME="infiniband/%k"
-
-can be used.  This will create device nodes named
-
-    /dev/infiniband/uverbs0
-
-and so on.  Since the RDMA userspace verbs should be safe for use by
-non-privileged users, you may want to add an appropriate MODE or GROUP
-to your udev rule.
-
-Permissions
------------
-
-To use IB verbs from userspace, a process must be able to access the
-appropriate /dev/infiniband/uverbsN special device file.  You can
-check the permissions on this file with the command
-
-	ls -l /dev/infiniband/uverbs*
-
-Make sure that the permissions on these files are such that the
-user/group that your verbs program runs as can access the device file.
-
-To use IB verbs from userspace, a process must also have permission to
-tell the kernel to lock sufficient memory for all of your registered
-memory regions as well as the memory used internally by IB resources
-such as queue pairs (QPs) and completion queues (CQs).  To check your
-resource limits, use the command
-
-	ulimit -l
-
-(or "limit memorylocked" for csh-like shells).
-
-If you see a small number such as 32 (the units are KB) then you will
-need to increase this limit.  This is usually done for ordinary users
-via the file /etc/security/limits.conf.  More configuration may be
-necessary if you are logging in via OpenSSH and your sshd is
-configured to use privilege separation.
-
-Valgrind support
-----------------
-
-When running applications that use libibverbs under the Valgrind
-memory-checking debugger, Valgrind will falsely report "read from
-uninitialized" for memory that was initialized by the kernel drivers.
-Specifically, Valgrind cannot see when kernel drivers write to
-userspace memory, so when the process reads from that memory, Valgrind
-incorrectly assumes that the memory contents are uninitialized, and
-therefore raises a warning.
-
-libibverbs can be built with specific support for the Valgrind
-memory-checking debugger by specifying the --with-valgrind command
-line argument to configure.  This flag enables code in libibverbs to
-tell Valgrind "this memory may look uninitialized, but it's really
-OK," which therefore suppresses the incorrect "read from
-uninitialized" warnings.  This code adds trivial overhead to the
-critical performance path, so it is disabled by default.  The intent
-is that production users can use a "normal" build of libibverbs and
-developers can use the "valgrind debug" build by simply switching
-their LD_LIBRARY_PATH environment variables.
-
-Libibverbs needs some header files from Valgrind in order to compile
-this support; it is important to use the header files from the same
-version of Valgrind that will be used at run time.  You may need to
-specify the directory where Valgrind's header files are installed as
-an argument to --with-valgrind.  For example
-
-	./configure --with-valgrind=/opt/valgrind
-
-will make the libibverbs build look for valgrind headers in
-/opt/valgrind/include
-
-Reporting bugs
-==============
-
-Bugs should be reported to the OpenFabrics mailing list
-<general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org>.  In your bug report, please include:
-
- * Information about your system:
-   - Linux distribution and version
-   - Linux kernel and version
-   - InfiniBand/iWARP hardware and firmware version
-   - ... any other relevant information
-
- * How to reproduce the bug.  Command line arguments for a libibverbs
-   example program or source code that other developers can
-   compile and run is most convenient.
-
- * If the bug is a crash, the exact output printed out when the crash
-   occurred, including any kernel messages produced.
-
- * If a verbs call is mysteriously returning an error or failing, the
-   output of "strace -ewrite -ewrite=all <command>".
-
-Submitting patches
-==================
-
-Patches should also be submitted to the OpenFabrics mailing list
-<general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org>.  Please use unified diff form (the -u
-option to GNU diff), and include a good description of what your patch
-does and why it should be applied.  If your patch fixes a bug, please
-make sure to describe the bug and how your fix works.
-
-Please include a change to the ChangeLog file (in standard GNU
-changelog format) as part of your patch.
-
-Make sure that your contribution can be licensed under the same
-license as the original code you are patching, and that you have all
-necessary permissions to release your work.
-
-TODO
-====
-
-1.1 series
-----------
-
-The libibverbs API and ABI are frozen for all releases in the 1.1
-series.  Methods were added to struct ibv_context to implement the
-following features, so it should be possible to add them in a future
-release in the 1.1 series:
-
- * Memory window (MW) support.
-
- * Implement the reregister memory region (MR) verb.  We will add an
-   extension to the IB spec to allow the application to indicate that
-   the region is only being extended, and that operations in progress
-   should _not_ fail (contrary to the IB spec, which states that
-   reregister must be implemented so that it behaves equivalently to a
-   deregister followed by a register).
-
-Other possibilities
--------------------
-
-There are no plans to implement the following features, which would be
-needed for completeness but don't seem particularly useful.  However,
-if there is demand from application developers or an implementation is
-contributed, then the feature may be added.
-
- * Implement the query address handle (AH) verb.
- * Implement the query memory region (MR) verb.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/9] move libibcm documentation to Documentation/

[Christoph Hellwig]

And drop bits that are outdated or replaced by top-level Documentation.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 Documentation/libibcm.md | 16 ++++++++++++++++
 libibcm/README           | 28 ----------------------------
 2 files changed, 16 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/libibcm.md
 delete mode 100644 libibcm/README

diff --git a/Documentation/libibcm.md b/Documentation/libibcm.md
new file mode 100644
index 0000000..663e773
--- /dev/null
+++ b/Documentation/libibcm.md
@@ -0,0 +1,16 @@
+# Device files
+
+The userspace CM uses a device file per adapter present.
+
+To create the appropriate character device file automatically with
+udev, a rule like
+
+    KERNEL="ucm*", NAME="infiniband/%k", MODE="0666"
+
+can be used.  This will create the device node named
+
+    /dev/infiniband/ucm0
+
+for the first HCA in the system, or you can create it manually
+
+  mknod /dev/infiniband/ucm0 c 231 224
diff --git a/libibcm/README b/libibcm/README
deleted file mode 100644
index 4dda13c..0000000
--- a/libibcm/README
+++ /dev/null
@@ -1,28 +0,0 @@
-This README is for userspace cm library.
-
-Building
-
-To make this directory, run:
-./autogen.sh && ./configure && make && make install
-
-Typically the autogen and configure steps only need be done the first
-time unless configure.in or Makefile.am changes.
-
-Libraries are installed by default at /usr/local/lib.
-
-Device files
-
-The userspace CM uses a device file per adapter present.
-
-To create the appropriate character device file automatically with
-udev, a rule like
-
-    KERNEL="ucm*", NAME="infiniband/%k", MODE="0666"
-
-can be used.  This will create the device node named
-
-    /dev/infiniband/ucm0
-
-for the first HCA in the system, or you can create it manually
-
-  mknod /dev/infiniband/ucm0 c 231 224
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/9] move librdmacm documentation to Documentation/

[Christoph Hellwig]

And drop bits that are outdated or replaced by top-level Documentation.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 Documentation/librdmacm.md | 46 ++++++++++++++++++++++++++++++++++
 librdmacm/README           | 61 ----------------------------------------------
 2 files changed, 46 insertions(+), 61 deletions(-)
 create mode 100644 Documentation/librdmacm.md
 delete mode 100644 librdmacm/README

diff --git a/Documentation/librdmacm.md b/Documentation/librdmacm.md
new file mode 100644
index 0000000..5eb8d31
--- /dev/null
+++ b/Documentation/librdmacm.md
@@ -0,0 +1,46 @@
+# Device files
+
+The userspace CMA uses a single device file regardless of the number
+of adapters or ports present.
+
+To create the appropriate character device file automatically with
+udev, a rule like
+
+    KERNEL="rdma_cm", NAME="infiniband/%k", MODE="0666"
+
+can be used.  This will create the device node named
+
+    /dev/infiniband/rdma_cm
+
+or you can create it manually
+
+  mknod /dev/infiniband/rdma_cm c 231 255
+
+
+# Common issues
+
+Using multiple interfaces
+	The librdmacm does support multiple interfaces.  To make use
+	of multiple interfaces, however, you need to instruct linux
+	to only send ARP reples on the interface targetted in the ARP
+	request.  This can be done using a command similar to the
+	following:
+
+	sysctl -w net.ipv4.conf.all.arp_ignore=2
+
+	Without this change, it's possible for linux to resopnd to ARP
+	requests on a different interface (IP address) than the IP
+	address carried in the ARP request.  This causes the RDMA stack
+	to incorrectly map the remote IP address to the wrong RDMA
+	device.
+
+Using loopback
+	The librdmacm relies on ARP to resolve IP address to RDMA
+	addresses.  To support loopback connections between different
+	ports on the same system, ARP must be enabled for local
+	resolution:
+
+	sysctl net.ipv4.conf.all.accept_local=1
+
+	Without this setting, loopback connections may timeout
+	during address resolution.
diff --git a/librdmacm/README b/librdmacm/README
deleted file mode 100644
index e1f2227..0000000
--- a/librdmacm/README
+++ /dev/null
@@ -1,61 +0,0 @@
-This README is for userspace RDMA cm library.
-
-
-Building
-========
-To make this directory, run:
-./autogen.sh && ./configure && make && make install
-
-Typically the autogen and configure steps only need be done the first
-time unless configure.in or Makefile.am changes.
-
-Libraries are installed by default at /usr/local/lib.
-
-
-Device files
-============
-The userspace CMA uses a single device file regardless of the number
-of adapters or ports present.
-
-To create the appropriate character device file automatically with
-udev, a rule like
-
-    KERNEL="rdma_cm", NAME="infiniband/%k", MODE="0666"
-
-can be used.  This will create the device node named
-
-    /dev/infiniband/rdma_cm
-
-or you can create it manually
-
-  mknod /dev/infiniband/rdma_cm c 231 255
-
-
-Common issues
-=============
-
-Using multiple interfaces
-	The librdmacm does support multiple interfaces.  To make use
-	of multiple interfaces, however, you need to instruct linux
-	to only send ARP reples on the interface targetted in the ARP
-	request.  This can be done using a command similar to the
-	following:
-
-	sysctl -w net.ipv4.conf.all.arp_ignore=2
-
-	Without this change, it's possible for linux to resopnd to ARP
-	requests on a different interface (IP address) than the IP
-	address carried in the ARP request.  This causes the RDMA stack
-	to incorrectly map the remote IP address to the wrong RDMA
-	device.
-
-Using loopback
-	The librdmacm relies on ARP to resolve IP address to RDMA
-	addresses.  To support loopback connections between different
-	ports on the same system, ARP must be enabled for local
-	resolution:
-
-	sysctl net.ipv4.conf.all.accept_local=1
-
-	Without this setting, loopback connections may timeout
-	during address resolution.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 8/9] move srp_daemon documentation to Documentation/

[Christoph Hellwig]

And drop bits that are outdated or replaced by top-level Documentation.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 Documentation/ibsrpdm.md | 41 ++++++++++++++++++++++++
 srp_daemon/README        | 82 ------------------------------------------------
 2 files changed, 41 insertions(+), 82 deletions(-)
 create mode 100644 Documentation/ibsrpdm.md
 delete mode 100644 srp_daemon/README

diff --git a/Documentation/ibsrpdm.md b/Documentation/ibsrpdm.md
new file mode 100644
index 0000000..0fc544d
--- /dev/null
+++ b/Documentation/ibsrpdm.md
@@ -0,0 +1,41 @@
+# Using ibsrpdm
+
+ibsrpdm is used for discovering and connecting to SRP SCSI targets on
+InfiniBand fabrics.  These targets can be accessed with the InfiniBand SRP
+initiator module, "ib_srp," included in Linux kernels 2.6.15 and newer.
+
+To run ibsrpdm, the ib_umad module must be loaded, as well as an appropriate
+low-level driver for the installed IB hardware.
+
+With no command line parameters, ibsrpdm displays information about
+SRP targets in human-readable form:
+
+    # ibsrpdm
+    IO Unit Info:
+        port LID:        0009
+        port GID:        fe800000000000000005ad00000013e9
+        change ID:       73b0
+        max controllers: 0x01
+
+        controller[  1]
+            GUID:      0005ad00000013e7
+            vendor ID: 0005ad
+            device ID: 0005ad
+            IO class : 0100
+            ID:        Topspin SRP/FC TCA
+            service entries: 2
+                service[  0]: 0000000000000066 / SRP.T10:20030003BA27CC7A
+                service[  1]: 0000000000000066 / SRP.T10:20030003BA27CF53
+
+With the "-c" flag, ibsrpdm displays information in a form that can be
+written to the kernel SRP initiators add_target file to connect to the
+SRP targets.  For example:
+
+    # ibsrpdm -c
+    id_ext=20030003BA27CC7A,ioc_guid=0005ad00000013e7,dgid=fe800000000000000005ad00000013e9,pkey=ffff,service_id=0000000000000066
+    id_ext=20030003BA27CF53,ioc_guid=0005ad00000013e7,dgid=fe800000000000000005ad00000013e9,pkey=ffff,service_id=0000000000000066
+
+Given this, the command below will connect to the first target
+discovered from the first port of the local HCA device "mthca0":
+
+    # echo -n id_ext=20030003BA27CC7A,ioc_guid=0005ad00000013e7,dgid=fe800000000000000005ad00000013e9,pkey=ffff,service_id=0000000000000066 > /sys/class/infiniband_srp/srp-mthca0-1/add_target
diff --git a/srp_daemon/README b/srp_daemon/README
deleted file mode 100644
index c44f11c..0000000
--- a/srp_daemon/README
+++ /dev/null
@@ -1,82 +0,0 @@
-Introduction
-============
-
-srptools is a package of tools for discovering and connecting to SRP
-SCSI targets on InfiniBand fabrics.  These targets can be accessed
-with the InfiniBand SRP initiator module, "ib_srp," included in Linux
-kernels 2.6.15 and newer.
-
-Using srptools
-==============
-
-srptools currently contains only a single executable, ibsrpdm.  To run
-ibsrpdm, the ib_umad module must be loaded, as well as an appropriate
-low-level driver for the installed IB hardware -- for example,
-ib_mthca for a Mellanox HCA, ib_ipath for a QLogic HCA, or hcad_mod
-for an IBM eHCA.
-
-With no command line parameters, ibsrpdm displays information about
-SRP targets in human-readable form:
-
-    # ibsrpdm
-    IO Unit Info:
-        port LID:        0009
-        port GID:        fe800000000000000005ad00000013e9
-        change ID:       73b0
-        max controllers: 0x01
-
-        controller[  1]
-            GUID:      0005ad00000013e7
-            vendor ID: 0005ad
-            device ID: 0005ad
-            IO class : 0100
-            ID:        Topspin SRP/FC TCA
-            service entries: 2
-                service[  0]: 0000000000000066 / SRP.T10:20030003BA27CC7A
-                service[  1]: 0000000000000066 / SRP.T10:20030003BA27CF53
-
-With the "-c" flag, ibsrpdm displays information in a form that can be
-written to the kernel SRP initiators add_target file to connect to the
-SRP targets.  For example:
-
-    # ibsrpdm -c
-    id_ext=20030003BA27CC7A,ioc_guid=0005ad00000013e7,dgid=fe800000000000000005ad00000013e9,pkey=ffff,service_id=0000000000000066
-    id_ext=20030003BA27CF53,ioc_guid=0005ad00000013e7,dgid=fe800000000000000005ad00000013e9,pkey=ffff,service_id=0000000000000066
-
-Given this, the command below will connect to the first target
-discovered from the first port of the local HCA device "mthca0":
-
-    # echo -n id_ext=20030003BA27CC7A,ioc_guid=0005ad00000013e7,dgid=fe800000000000000005ad00000013e9,pkey=ffff,service_id=0000000000000066 > /sys/class/infiniband_srp/srp-mthca0-1/add_target
-
-Reporting bugs
-==============
-
-Bugs should be reported to the OpenIB mailing list
-<openib-general-0P3JtQMG0aQdnm+yROfE0A@public.gmane.org>.  In your bug report, please include:
-
- * Information about your system:
-   - Linux distribution and version
-   - Linux kernel and version
-   - InfiniBand hardware and firmware version
-   - ... any other relevant information
-
- * How to reproduce the bug.
-
- * If the bug is a crash, the exact output printed out when the crash
-   occurred, including any kernel messages produced.
-
-Submitting patches
-==================
-
-Patches should also be submitted to the OpenIB mailing list
-<openib-general-0P3JtQMG0aQdnm+yROfE0A@public.gmane.org>.  Please use unified diff form (the -u
-option to GNU diff), and include a good description of what your patch
-does and why it should be applied.  If your patch fixes a bug, please
-make sure to describe the bug and how your fix works.
-
-Please include a change to the ChangeLog file (in standard GNU
-changelog format) as part of your patch.
-
-Make sure that your contribution can be licensed under the same
-license as the original code you are patching, and that you have all
-necessary permissions to release your work.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 9/9] remove iwpmd/README

[Christoph Hellwig]

No useful information left in it for the modern-day package.

Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
---
 iwpmd/README | 36 ------------------------------------
 1 file changed, 36 deletions(-)
 delete mode 100644 iwpmd/README

diff --git a/iwpmd/README b/iwpmd/README
deleted file mode 100644
index 49a2890..0000000
--- a/iwpmd/README
+++ /dev/null
@@ -1,36 +0,0 @@
-iWarp Port Mapper Daemon - iwpmd
-
-DESCRIPTION
-
-iwpmd provides a user space service (iwpmd) for the iWarp drivers
-to claim tcp ports through the standard socket interface.
-The drivers currently using the service are Intel nes and Chelsio cxgb4.
-
-PREREQUISITES
-
-iwpmd requires libnl-1 or higher version and the corresponding libnl-devel
-to be installed.
-
-The kernel space support for the port mapper is part of the iw_cm module.
-The ib_core module includes netlink support, which is used by the port mapper 
-clients to exchange messages with iwpmd. Both modules iw_cm and ib_core need to 
-be loaded in order for the iwpmd service to start successfully.
-
-If the iwpmd is installed, but the required modules aren't loaded, you need to
-load the modules and then restart the iwpmd service.
-
-STARTING THE SERVICE
-
-After installing an OFED package which includes iwpmd, the service should start 
-automatically after reboot.
-
-To check if the service is running:
-ps aux | grep iwpmd
-
-To start/stop the iwpmd service use:
-service iwpmd start
-service iwpmd stop
-
-With systemd, to start/stop the iwpmd service use:
-systemctl start iwpmd
-systemctl stop iwpmd
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/9] move libibverbs documentation to Documentation/

[Parav Pandit]

Little unrelated but related to directory movement?

Is there a desire to move SRP, iSER initiator to scsi directory
instead of infiniband/drivers/ulp similar to other scsi initiator low
level drivers?

Parav


On Mon, Sep 19, 2016 at 9:26 PM, Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org> wrote:
> And drop bits that are outdated or replaced by top-level Documentation.
>
> Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> ---
>  Documentation/libibverbs.md |  58 ++++++++++++++++
>  libibverbs/README           | 164 --------------------------------------------
>  2 files changed, 58 insertions(+), 164 deletions(-)
>  create mode 100644 Documentation/libibverbs.md
>  delete mode 100644 libibverbs/README
>
> diff --git a/Documentation/libibverbs.md b/Documentation/libibverbs.md
> new file mode 100644
> index 0000000..cbe076e
> --- /dev/null
> +++ b/Documentation/libibverbs.md
> @@ -0,0 +1,58 @@
> +# Introduction
> +
> +libibverbs is a library that allows programs to use RDMA "verbs" for
> +direct access to RDMA (currently InfiniBand and iWARP) hardware from
> +userspace.  For more information on RDMA verbs, see the InfiniBand
> +Architecture Specification vol. 1, especially chapter 11, and the RDMA
> +Consortium's RDMA Protocol Verbs Specification.
> +
> +# Using libibverbs
> +
> +### Device nodes
> +
> +The verbs library expects special character device files named
> +/dev/infiniband/uverbsN to be created.  When you load the kernel
> +modules, including both the low-level driver for your IB hardware as
> +well as the ib_uverbs module, you should see one or more uverbsN
> +entries in /sys/class/infiniband_verbs in addition to the
> +/dev/infiniband/uverbsN character device files.
> +
> +To create the appropriate character device files automatically with
> +udev, a rule like
> +
> +    KERNEL="uverbs*", NAME="infiniband/%k"
> +
> +can be used.  This will create device nodes named
> +
> +    /dev/infiniband/uverbs0
> +
> +and so on.  Since the RDMA userspace verbs should be safe for use by
> +non-privileged users, you may want to add an appropriate MODE or GROUP
> +to your udev rule.
> +
> +### Permissions
> +
> +To use IB verbs from userspace, a process must be able to access the
> +appropriate /dev/infiniband/uverbsN special device file.  You can
> +check the permissions on this file with the command
> +
> +       ls -l /dev/infiniband/uverbs*
> +
> +Make sure that the permissions on these files are such that the
> +user/group that your verbs program runs as can access the device file.
> +
> +To use IB verbs from userspace, a process must also have permission to
> +tell the kernel to lock sufficient memory for all of your registered
> +memory regions as well as the memory used internally by IB resources
> +such as queue pairs (QPs) and completion queues (CQs).  To check your
> +resource limits, use the command
> +
> +       ulimit -l
> +
> +(or "limit memorylocked" for csh-like shells).
> +
> +If you see a small number such as 32 (the units are KB) then you will
> +need to increase this limit.  This is usually done for ordinary users
> +via the file /etc/security/limits.conf.  More configuration may be
> +necessary if you are logging in via OpenSSH and your sshd is
> +configured to use privilege separation.
> diff --git a/libibverbs/README b/libibverbs/README
> deleted file mode 100644
> index 848eb05..0000000
> --- a/libibverbs/README
> +++ /dev/null
> @@ -1,164 +0,0 @@
> -Introduction
> -============
> -
> -libibverbs is a library that allows programs to use RDMA "verbs" for
> -direct access to RDMA (currently InfiniBand and iWARP) hardware from
> -userspace.  For more information on RDMA verbs, see the InfiniBand
> -Architecture Specification vol. 1, especially chapter 11, and the RDMA
> -Consortium's RDMA Protocol Verbs Specification.
> -
> -Using libibverbs
> -================
> -
> -Device nodes
> -------------
> -
> -The verbs library expects special character device files named
> -/dev/infiniband/uverbsN to be created.  When you load the kernel
> -modules, including both the low-level driver for your IB hardware as
> -well as the ib_uverbs module, you should see one or more uverbsN
> -entries in /sys/class/infiniband_verbs in addition to the
> -/dev/infiniband/uverbsN character device files.
> -
> -To create the appropriate character device files automatically with
> -udev, a rule like
> -
> -    KERNEL="uverbs*", NAME="infiniband/%k"
> -
> -can be used.  This will create device nodes named
> -
> -    /dev/infiniband/uverbs0
> -
> -and so on.  Since the RDMA userspace verbs should be safe for use by
> -non-privileged users, you may want to add an appropriate MODE or GROUP
> -to your udev rule.
> -
> -Permissions
> ------------
> -
> -To use IB verbs from userspace, a process must be able to access the
> -appropriate /dev/infiniband/uverbsN special device file.  You can
> -check the permissions on this file with the command
> -
> -       ls -l /dev/infiniband/uverbs*
> -
> -Make sure that the permissions on these files are such that the
> -user/group that your verbs program runs as can access the device file.
> -
> -To use IB verbs from userspace, a process must also have permission to
> -tell the kernel to lock sufficient memory for all of your registered
> -memory regions as well as the memory used internally by IB resources
> -such as queue pairs (QPs) and completion queues (CQs).  To check your
> -resource limits, use the command
> -
> -       ulimit -l
> -
> -(or "limit memorylocked" for csh-like shells).
> -
> -If you see a small number such as 32 (the units are KB) then you will
> -need to increase this limit.  This is usually done for ordinary users
> -via the file /etc/security/limits.conf.  More configuration may be
> -necessary if you are logging in via OpenSSH and your sshd is
> -configured to use privilege separation.
> -
> -Valgrind support
> -----------------
> -
> -When running applications that use libibverbs under the Valgrind
> -memory-checking debugger, Valgrind will falsely report "read from
> -uninitialized" for memory that was initialized by the kernel drivers.
> -Specifically, Valgrind cannot see when kernel drivers write to
> -userspace memory, so when the process reads from that memory, Valgrind
> -incorrectly assumes that the memory contents are uninitialized, and
> -therefore raises a warning.
> -
> -libibverbs can be built with specific support for the Valgrind
> -memory-checking debugger by specifying the --with-valgrind command
> -line argument to configure.  This flag enables code in libibverbs to
> -tell Valgrind "this memory may look uninitialized, but it's really
> -OK," which therefore suppresses the incorrect "read from
> -uninitialized" warnings.  This code adds trivial overhead to the
> -critical performance path, so it is disabled by default.  The intent
> -is that production users can use a "normal" build of libibverbs and
> -developers can use the "valgrind debug" build by simply switching
> -their LD_LIBRARY_PATH environment variables.
> -
> -Libibverbs needs some header files from Valgrind in order to compile
> -this support; it is important to use the header files from the same
> -version of Valgrind that will be used at run time.  You may need to
> -specify the directory where Valgrind's header files are installed as
> -an argument to --with-valgrind.  For example
> -
> -       ./configure --with-valgrind=/opt/valgrind
> -
> -will make the libibverbs build look for valgrind headers in
> -/opt/valgrind/include
> -
> -Reporting bugs
> -==============
> -
> -Bugs should be reported to the OpenFabrics mailing list
> -<general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org>.  In your bug report, please include:
> -
> - * Information about your system:
> -   - Linux distribution and version
> -   - Linux kernel and version
> -   - InfiniBand/iWARP hardware and firmware version
> -   - ... any other relevant information
> -
> - * How to reproduce the bug.  Command line arguments for a libibverbs
> -   example program or source code that other developers can
> -   compile and run is most convenient.
> -
> - * If the bug is a crash, the exact output printed out when the crash
> -   occurred, including any kernel messages produced.
> -
> - * If a verbs call is mysteriously returning an error or failing, the
> -   output of "strace -ewrite -ewrite=all <command>".
> -
> -Submitting patches
> -==================
> -
> -Patches should also be submitted to the OpenFabrics mailing list
> -<general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org>.  Please use unified diff form (the -u
> -option to GNU diff), and include a good description of what your patch
> -does and why it should be applied.  If your patch fixes a bug, please
> -make sure to describe the bug and how your fix works.
> -
> -Please include a change to the ChangeLog file (in standard GNU
> -changelog format) as part of your patch.
> -
> -Make sure that your contribution can be licensed under the same
> -license as the original code you are patching, and that you have all
> -necessary permissions to release your work.
> -
> -TODO
> -====
> -
> -1.1 series
> -----------
> -
> -The libibverbs API and ABI are frozen for all releases in the 1.1
> -series.  Methods were added to struct ibv_context to implement the
> -following features, so it should be possible to add them in a future
> -release in the 1.1 series:
> -
> - * Memory window (MW) support.
> -
> - * Implement the reregister memory region (MR) verb.  We will add an
> -   extension to the IB spec to allow the application to indicate that
> -   the region is only being extended, and that operations in progress
> -   should _not_ fail (contrary to the IB spec, which states that
> -   reregister must be implemented so that it behaves equivalently to a
> -   deregister followed by a register).
> -
> -Other possibilities
> --------------------
> -
> -There are no plans to implement the following features, which would be
> -needed for completeness but don't seem particularly useful.  However,
> -if there is demand from application developers or an implementation is
> -contributed, then the feature may be added.
> -
> - * Implement the query address handle (AH) verb.
> - * Implement the query memory region (MR) verb.
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: update rdma-plumbing Documentation

[Jason Gunthorpe]

On Mon, Sep 19, 2016 at 08:56:24AM -0700, Christoph Hellwig wrote:
> Get rid of the per-subproject README files and instead improve the top-level
> README.md as well as adding a few new files for more details to Documentation/

Thanks Christoph, this all looks great to me.

Thanks for taking the time to switch to markdown, since we are decided
to use github that will work well.

If you don't mind I'll squish patch 2 'remove empty documentation
files' into 'Remove the auto* based build systems'

For now I'll pop these onto my tree so they don't get lost.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: update rdma-plumbing Documentation

[Christoph Hellwig]

On Mon, Sep 19, 2016 at 01:25:50PM -0600, Jason Gunthorpe wrote:
> If you don't mind I'll squish patch 2 'remove empty documentation
> files' into 'Remove the auto* based build systems'

Sure, that's where it should have been anyway.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html