* update rdma-plumbing Documentation
From: Christoph Hellwig @ 2016-09-19 15:56 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
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
^ permalink raw reply
* [PATCH 1/9] add reporting bugs and submitting patches sections to README.md
From: Christoph Hellwig @ 2016-09-19 15:56 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
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
^ permalink raw reply related
* [PATCH 2/9] remove empty documentation files
From: Christoph Hellwig @ 2016-09-19 15:56 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
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
^ permalink raw reply
* [PATCH 3/9] remove README files in the provider directories
From: Christoph Hellwig @ 2016-09-19 15:56 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
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
^ permalink raw reply related
* [PATCH 4/9] move rxe documentation to Documentation/
From: Christoph Hellwig @ 2016-09-19 15:56 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
[-- 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
^ permalink raw reply related
* [PATCH 5/9] move libibverbs documentation to Documentation/
From: Christoph Hellwig @ 2016-09-19 15:56 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
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
^ permalink raw reply related
* [PATCH 6/9] move libibcm documentation to Documentation/
From: Christoph Hellwig @ 2016-09-19 15:56 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
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
^ permalink raw reply related
* [PATCH 7/9] move librdmacm documentation to Documentation/
From: Christoph Hellwig @ 2016-09-19 15:56 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
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
^ permalink raw reply related
* [PATCH 8/9] move srp_daemon documentation to Documentation/
From: Christoph Hellwig @ 2016-09-19 15:56 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
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
^ permalink raw reply related
* [PATCH 9/9] remove iwpmd/README
From: Christoph Hellwig @ 2016-09-19 15:56 UTC (permalink / raw)
To: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
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
^ permalink raw reply related
* Re: VERBOSE flags
From: Doug Ledford @ 2016-09-19 16:03 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: linux-rdma
In-Reply-To: <20160919061558.GG3273-2ukJVAZIZ/Y@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2180 bytes --]
On 9/19/2016 2:15 AM, Leon Romanovsky wrote:
> On Sun, Sep 18, 2016 at 04:35:37PM -0400, Doug Ledford wrote:
> Doug,
> The function pointers will cause us to create two similar functions
> (debug/regular) for every important function. It will leave to code
> duplication and/or introducing of new code to fill additional fields
> in returns to debug functions, so they will be able to print it.
That's situationally specific. The original patch you posted that I
said no to is an example of where this wouldn't have been true.
Basically it all boils down to whether or not your debug code can be a
wrapper of your existing function or if it needs to be embedded in the
middle of it. If the latter, then you are more likely to have code
duplication as you point out. But, then refactoring code can help with
that problem too.
> I wanted to propose to use tracepoints to provide debug information in
> data paths. The tracepoints infrastructure uses hooks in the code with
> minimal impact on performance.
Yes, but one of the things you said before was "zero impact on normal
operations", but with tracepoints you just said "minimal impact". So it
sounds like tracepoints don't meet your own initial requirements. I'm
not against them, but utilizing the entry points allows for achievment
of the "zero impact" requirement. And as Denny pointed out, some things
can't be done with tracepoints. So, the final solution might be a mix
of different things including different entry points, tracepoints, and
some core infrastructure.
>
>> Then we can drop the CONFIG_*_DEBUG options out of all of the
>> drivers. That would be my preference. I don't want any compile time
>> options because you never will be running a debug kernel when you need
>> it. Per device, run time selectable so that you get 0 overhead in the
>> normal case is what I would like to see.
>
> Great,
> We are aligned on this point, so do I. I see no reason in special compiled
> kernel or global module parameter to print debug prints for whole driver.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH] ibacm: Handle EP expiration time
From: Yuval Shaia @ 2016-09-19 16:40 UTC (permalink / raw)
To: Hefty, Sean; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB08D0BC-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Mon, Sep 19, 2016 at 03:51:22PM +0000, Hefty, Sean wrote:
> > > > static struct acmp_dest *
> > > > acmp_acquire_dest(struct acmp_ep *ep, uint8_t addr_type, const
> > uint8_t
> > > > *addr)
> > > > {
> > > > @@ -366,6 +382,15 @@ acmp_acquire_dest(struct acmp_ep *ep, uint8_t
> > > > addr_type, const uint8_t *addr)
> > > > acm_log(2, "%s\n", log_data);
> > > > lock_acquire(&ep->lock);
> > > > dest = acmp_get_dest(ep, addr_type, addr);
> > > > + if (dest && is_dest_ready(dest)) {
> > >
> > > I think it would be clearer to just perform the state check here and
> > either avoid the timeout check or merge it with the if statement below.
> >
> > As stated above, i cannot ignore the timeout so will merge it here.
> >
> > >
> > > > + acm_log(2, "Record valid for the next %ld minute(s)\n",
> > > > + dest->addr_timeout - time_stamp_min());
> > > > + if (time_stamp_min() >= dest->addr_timeout) {
>
> We also check addr_timeout here. (Sorry, it's been a long while since I've looked at this code.) My question regarding timeouts are around why do we need two checks?
First one is for log only.
If you think it is not needed then i'll remove it, otherwise i will take it
out to an helper variable and use it in both.
> --
> 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
^ permalink raw reply
* RE: [PATCH] ibacm: Handle EP expiration time
From: Hefty, Sean @ 2016-09-19 16:50 UTC (permalink / raw)
To: Yuval Shaia; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20160919164057.GA28264-Hxa29pjIrETlQW142y8m19+IiqhCXseY@public.gmane.org>
> > > > > static struct acmp_dest *
> > > > > acmp_acquire_dest(struct acmp_ep *ep, uint8_t addr_type, const
> > > uint8_t
> > > > > *addr)
> > > > > {
> > > > > @@ -366,6 +382,15 @@ acmp_acquire_dest(struct acmp_ep *ep,
> uint8_t
> > > > > addr_type, const uint8_t *addr)
> > > > > acm_log(2, "%s\n", log_data);
> > > > > lock_acquire(&ep->lock);
> > > > > dest = acmp_get_dest(ep, addr_type, addr);
> > > > > + if (dest && is_dest_ready(dest)) {
> > > >
> > > > I think it would be clearer to just perform the state check here
> and
> > > either avoid the timeout check or merge it with the if statement
> below.
> > >
> > > As stated above, i cannot ignore the timeout so will merge it here.
> > >
> > > >
> > > > > + acm_log(2, "Record valid for the next %ld
> minute(s)\n",
> > > > > + dest->addr_timeout - time_stamp_min());
> > > > > + if (time_stamp_min() >= dest->addr_timeout) {
> >
> > We also check addr_timeout here. (Sorry, it's been a long while
> since I've looked at this code.) My question regarding timeouts are
> around why do we need two checks?
>
> First one is for log only.
okay
> If you think it is not needed then i'll remove it, otherwise i will
> take it
> out to an helper variable and use it in both.
I think we're good then.
--
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
^ permalink raw reply
* Re: [PATCH libibverbs v2 1/3] Add new call ibv_cmd_create_ah_ex which supports extra parameters
From: Jason Gunthorpe @ 2016-09-19 16:59 UTC (permalink / raw)
To: Knut Omang; +Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Mukesh Kacker
In-Reply-To: <1474259792.20134.117.camel-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Mon, Sep 19, 2016 at 06:36:32AM +0200, Knut Omang wrote:
> diff --git a/src/libibverbs.map b/src/libibverbs.map
> index 5134bd9..979980d 100644
> +++ b/src/libibverbs.map
> @@ -118,5 +118,15 @@ IBVERBS_1.1 {
> ibv_cmd_create_qp_ex2;
> ibv_cmd_open_qp;
> ibv_cmd_rereg_mr;
> } IBVERBS_1.0;
>
> +IBVERBS_1.2 {
> +} IBVERBS_1.1;
This is the right idea, but we won't be going back to fix the bad tags
from 1.2 and other releases so this can be dropped.
> +IBVERBS_1.3 {
> +} IBVERBS_1.2;
If you pull from Doug's tree right now you'll get a populated version
of this stanza
> +IBVERBS_1.4 {
> + global:
> + ibv_cmd_create_ah_ex;
> +} IBVERBS_1.3;
Right. Doug will have to figure out a process for these, eg if he
hasn't released 1.3 yet then this can be folded into 1.3.
It is critical that once a release is made that the existing stanza's
not be changed.
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
^ permalink raw reply
* Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller
From: Parav Pandit @ 2016-09-19 17:00 UTC (permalink / raw)
To: Dalessandro, Dennis
Cc: leon@kernel.org, lizefan@huawei.com, linux-kernel@vger.kernel.org,
corbet@lwn.net, linux-rdma@vger.kernel.org,
cgroups@vger.kernel.org, ogerlitz@mellanox.com, hch@lst.de,
linux-security-module@vger.kernel.org, haggaie@mellanox.com,
hannes@cmpxchg.org, Hefty, Sean, akpm@linux-foundation.org,
james.l.morris@oracle.com, tj@kernel.org, liranl@mellanox.com
In-Reply-To: <1474290618.6520.23.camel@intel.com>
Hi Denny,
On Mon, Sep 19, 2016 at 6:40 PM, Dalessandro, Dennis
<dennis.dalessandro@intel.com> wrote:
> On Wed, 2016-09-14 at 12:36 +0530, Parav Pandit wrote:
>> Hi Dennis,
>>
>> Do you know how would HFI1 driver would work along with rdma cgroup?
>
> Keep in mind HFI1 driver has two "modes" of operation. We support
> verbs, and would surely fall in line with whatever cgroups do for IB
> core.
Thanks for the feedback.
> For our psm interface, not sure how cgroups would come into play.
> Psm is designed to expose the hw to user and avoid the kernel when
> possible adding more kernel control is sort of contrary to that.
>
Yes, PSM is currently out of RDMA cgroup and in future we can take a
look on how things shape as subsystem if it does.
> Now that being said, Christoph recently made mention of maybe having a
> drivers/psm [1]. I really haven't had a chance to think about the
> implications of that, but maybe it's worth considering, after all we
> have two implementations, qib and hfi1. So anyway I'm not sure we need
> to be too concerned about cgroups right now as far as psm side of
> things goes.
>
o.k.
^ permalink raw reply
* Re: [PATCH 5/9] move libibverbs documentation to Documentation/
From: Parav Pandit @ 2016-09-19 17:02 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jason Gunthorpe, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-6-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
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
^ permalink raw reply
* [PATCH v2] ibacm: Handle EP expiration time
From: Yuval Shaia @ 2016-09-19 17:28 UTC (permalink / raw)
To: sean.hefty-ral2JQCrhuEAvxtiuMwx3w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Old destination records are removed from EP's dest_map after timeout is
expired in order to maintain a correct cache.
Signed-off-by: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
---
v0 -> v1:
* Move the status and timeout check to acmp_acquire_dest
* Fix typo (Record expiered).
* Use NULL instead of 0
v1 -> v2:
* (uint64_t)~0ULL instead of 0xFFFFFFFFFFFFFFFF
* Calculate expiration time once
---
prov/acmp/src/acmp.c | 32 +++++++++++++++++++++++---------
1 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/prov/acmp/src/acmp.c b/prov/acmp/src/acmp.c
index ec64631..a26ed83 100644
--- a/prov/acmp/src/acmp.c
+++ b/prov/acmp/src/acmp.c
@@ -356,16 +356,39 @@ acmp_put_dest(struct acmp_dest *dest)
}
}
+/* Caller must hold ep lock. */
+static void
+acmp_remove_dest(struct acmp_ep *ep, struct acmp_dest *dest)
+{
+ acm_log(2, "%s\n", dest->name);
+ tdelete(dest->address, &ep->dest_map[dest->addr_type - 1],
+ acmp_compare_dest);
+ acmp_put_dest(dest);
+}
+
static struct acmp_dest *
acmp_acquire_dest(struct acmp_ep *ep, uint8_t addr_type, const uint8_t *addr)
{
struct acmp_dest *dest;
+ int64_t rec_expr_minutes;
acm_format_name(2, log_data, sizeof log_data,
addr_type, addr, ACM_MAX_ADDRESS);
acm_log(2, "%s\n", log_data);
lock_acquire(&ep->lock);
dest = acmp_get_dest(ep, addr_type, addr);
+ if (dest && dest->state == ACMP_READY &&
+ dest->addr_timeout != (uint64_t)~0ULL) {
+ rec_expr_minutes = dest->addr_timeout - time_stamp_min();
+ if (rec_expr_minutes <= 0) {
+ acm_log(2, "Record expired\n");
+ acmp_remove_dest(ep, dest);
+ dest = NULL;
+ } else {
+ acm_log(2, "Record valid for the next %ld minute(s)\n",
+ rec_expr_minutes);
+ }
+ }
if (!dest) {
dest = acmp_alloc_dest(addr_type, addr);
if (dest) {
@@ -378,15 +401,6 @@ acmp_acquire_dest(struct acmp_ep *ep, uint8_t addr_type, const uint8_t *addr)
return dest;
}
-/* Caller must hold ep lock. */
-//static void
-//acmp_remove_dest(struct acmp_ep *ep, struct acmp_dest *dest)
-//{
-// acm_log(2, "%s\n", dest->name);
-// tdelete(dest->address, &ep->dest_map[dest->addr_type - 1], acmp_compare_dest);
-// acmp_put_dest(dest);
-//}
-
static struct acmp_request *acmp_alloc_req(uint64_t id, struct acm_msg *msg)
{
struct acmp_request *req;
--
1.7.1
--
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
^ permalink raw reply related
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
From: Jason Gunthorpe @ 2016-09-19 18:55 UTC (permalink / raw)
To: Hefty, Sean
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Devesh Sharma, Hal Rosenstock, Marciniszyn, Mike, Moni Shoua,
Steve Wise, Nikolova, Tatyana E, Vladimir Sokolovsky,
Yishai Hadas
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB08C5F3-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Fri, Sep 16, 2016 at 04:24:37PM +0000, Hefty, Sean wrote:
> > > I would. Mainly because it is tied to both the kernel uAPI (via
> > > netlink)and to librdmacm
> >
> > With what little I know about ibacm I'm inclined to agree. It seems
> > like a utility for librdmacm, and is consuming a kernel interface.
> >
> > Reconsider Sean?
>
> Yes - Doug made a good point. The librdmacm and ibacm share a
> protocol, which I think I ended up copying into both packages.
I would delete the windows support in that package if we take it into
rdma-core.
Is that OK?
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
^ permalink raw reply
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
From: Hefty, Sean @ 2016-09-19 18:58 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Devesh Sharma, Hal Rosenstock, Marciniszyn, Mike, Moni Shoua,
Steve Wise, Nikolova, Tatyana E, Vladimir Sokolovsky,
Yishai Hadas
In-Reply-To: <20160919185502.GA12436-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
> I would delete the windows support in that package if we take it into
> rdma-core.
>
> Is that OK?
That's fine with me. I haven't tested on windows in a long time. I'm not sure how usable it is, as no one is maintaining the libibverbs and libibumad windows ports.
--
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
^ permalink raw reply
* Re: update rdma-plumbing Documentation
From: Jason Gunthorpe @ 2016-09-19 19:25 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474300593-31922-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
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
^ permalink raw reply
* [PATCH] Support for Chelsio T6 devices
From: Steve Wise @ 2016-09-19 19:55 UTC (permalink / raw)
To: Gil Rockah; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
src/perftest_parameters.c | 1 +
src/perftest_parameters.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/perftest_parameters.c b/src/perftest_parameters.c
index a21b6eb..0d1ea2f 100755
--- a/src/perftest_parameters.c
+++ b/src/perftest_parameters.c
@@ -1326,6 +1326,7 @@ enum ctx_device ib_dev_name(struct ibv_context *context)
case 4 : dev_fname = CHELSIO_T4; break;
case 11 :
case 5 : dev_fname = CHELSIO_T5; break;
+ case 6 : dev_fname = CHELSIO_T6; break;
default : dev_fname = UNKNOWN; break;
}
diff --git a/src/perftest_parameters.h b/src/perftest_parameters.h
index 448e398..727a65f 100755
--- a/src/perftest_parameters.h
+++ b/src/perftest_parameters.h
@@ -269,7 +269,8 @@ enum ctx_device {
CONNECTX4 = 10,
CONNECTX4LX = 11,
QLOGIC_E4 = 12,
- QLOGIC_AH = 13
+ QLOGIC_AH = 13,
+ CHELSIO_T6 = 14
};
/* Units for rate limiter */
--
1.7.1
--
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
^ permalink raw reply related
* Re: update rdma-plumbing Documentation
From: Christoph Hellwig @ 2016-09-19 20:59 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160919192550.GA7486-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
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
^ permalink raw reply
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
From: Jason Gunthorpe @ 2016-09-19 22:54 UTC (permalink / raw)
To: Hefty, Sean
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Devesh Sharma, Hal Rosenstock, Marciniszyn, Mike, Moni Shoua,
Steve Wise, Nikolova, Tatyana E, Vladimir Sokolovsky,
Yishai Hadas
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373AB08D2CD-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Mon, Sep 19, 2016 at 06:58:52PM +0000, Hefty, Sean wrote:
> > I would delete the windows support in that package if we take it into
> > rdma-core.
> >
> > Is that OK?
>
> That's fine with me. I haven't tested on windows in a long time.
> I'm not sure how usable it is, as no one is maintaining the
> libibverbs and libibumad windows ports.
Okay, it is up now. I haven't done all the steps, but call it a draft.
https://github.com/jgunthorpe/rdma-plumbing/tree/master/ibacm
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
^ permalink raw reply
* Re: [PATCH libibverbs v2 1/3] Add new call ibv_cmd_create_ah_ex which supports extra parameters
From: Knut Omang @ 2016-09-20 4:42 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Mukesh Kacker
In-Reply-To: <20160919165942.GB11836-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Mon, 2016-09-19 at 10:59 -0600, Jason Gunthorpe wrote:
> On Mon, Sep 19, 2016 at 06:36:32AM +0200, Knut Omang wrote:
> > diff --git a/src/libibverbs.map b/src/libibverbs.map
> > index 5134bd9..979980d 100644
> > +++ b/src/libibverbs.map
> > @@ -118,5 +118,15 @@ IBVERBS_1.1 {
> > ibv_cmd_create_qp_ex2;
> > ibv_cmd_open_qp;
> > ibv_cmd_rereg_mr;
> > } IBVERBS_1.0;
> >
> > +IBVERBS_1.2 {
> > +} IBVERBS_1.1;
>
> This is the right idea, but we won't be going back to fix the bad tags
> from 1.2 and other releases so this can be dropped.
>
> > +IBVERBS_1.3 {
> > +} IBVERBS_1.2;
>
> If you pull from Doug's tree right now you'll get a populated version
> of this stanza
>
> > +IBVERBS_1.4 {
> > + global:
> > + ibv_cmd_create_ah_ex;
> > +} IBVERBS_1.3;
>
> Right. Doug will have to figure out a process for these, eg if he
> hasn't released 1.3 yet then this can be folded into 1.3.
>
> It is critical that once a release is made that the existing stanza's
> not be changed.
Ok, fine - I see no 1.3.x tag yet so will post av v3 with this fix now.
Thanks,
Knut
--
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
^ permalink raw reply
* [PATCH libibverbs v3 0/3] SIF related libibverbs patches
From: Knut Omang @ 2016-09-20 6:22 UTC (permalink / raw)
To: Doug Ledford; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Mukesh Kacker, Knut Omang
This is the initial patch series for the work of upstreaming the driver and
user level library for SIF, the new Oracle HCA.
These patches are needed to support SIF - Oracle's new Infiniband HCA stack
from user mode. A corresponding patch set for the kernel is needed.
Patch 1 introduces a new ibv_cmd_create_ah_ex under a new .so file version
IBVERBS_1.3 in order to preserve backward binary compatibility with older
provider builds.
We need patch 2 because we need a provider specific extension to the ibv_reg_mr response,
which breaks if alignment criterias are violated.
Patch 3 is similar to patch 2 except that no provider libs uses this code path
(kernel supported XRC send) until now, so no extra backward compatibility measures
are needed.
Changes since v2:
- Rebase to latest libibverbs (3b39733)
- Use IBVERBS_1.4 instead of 1.3 in map file
Changes since v1:
- Introduce the new ibv_cmd_create_ah_ex as a new version IBVERBS_1.3 in the
map file.
Knut Omang (3):
Add new call ibv_cmd_create_ah_ex which supports extra parameters
Add padding to get proper end alignment of ibv_reg_mr_resp
Provide remote XRC SRQ number in kernel post_send.
include/infiniband/driver.h | 4 +++-
include/infiniband/kern-abi.h | 2 +-
src/cmd.c | 55 +++++++++++++++++++++---------------
src/libibverbs.map | 6 +++-
4 files changed, 44 insertions(+), 23 deletions(-)
base-commit: 3b3973377f0dbccb11323b86e267308052cc4458
--
git-series 0.8.10
--
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox