Message-Id: <1548151235-386-3-git-send-email-joeln@il.ibm.com>
Date:   Tue, 22 Jan 2019 12:00:34 +0200
From:   Joel Nider <joeln@...ibm.com>
To:     Jonathan Corbet <corbet@....net>
Cc:     Jason Gunthorpe <jgg@...pe.ca>, Leon Romanovsky <leon@...nel.org>,
        Doug Ledford <dledford@...hat.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Joel Nider <joeln@...ibm.com>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH v3 2/3] docs-rst: driver-api: Add infiniband interface documentation

A short document regarding the user verbs interface implementation on
the kernel side. Also, the corresponding index entry in the
documentation tree.

Signed-off-by: Joel Nider <joeln@...ibm.com>
---
 Documentation/driver-api/index.rst      |  1 +
 Documentation/driver-api/infiniband.rst | 73 +++++++++++++++++++++++++++++++++
 2 files changed, 74 insertions(+)
 create mode 100644 Documentation/driver-api/infiniband.rst

diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index ab38ced..ecb3f8a5 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -28,6 +28,7 @@ available subsections can be seen below.
    regulator
    iio/index
    input
+   infiniband
    usb/index
    firewire
    pci/index
diff --git a/Documentation/driver-api/infiniband.rst b/Documentation/driver-api/infiniband.rst
new file mode 100644
index 0000000..2de47ff
--- /dev/null
+++ b/Documentation/driver-api/infiniband.rst
@@ -0,0 +1,73 @@
+==========================
+Infiniband Interface Guide
+==========================
+
+This guide is for people who wish to understand the implementation details of
+handler functions in the Infiniband subsystem. There are currently two system
+calls for executing Infiniband commands: write() and ioctl(). Older commands
+are sent to the kernel via write()s on the device files described in
+:doc:`../userspace-api/rdma_user_verbs`. New commands must use the ioctl()
+method. For completeness, both mechanisms are described here.
+
+The interface between userspace and kernel is kept in sync by checking the
+version number. In the kernel, it is defined by IB_USER_VERBS_ABI_VERSION
+(in include/uapi/rdma/ib_user_verbs.h).
+
+Write system call
+-----------------
+The entry point to the kernel is the ib_uverbs_write() function, which is
+invoked as a response to the 'write' system call. The requested function is
+looked up from an array called uverbs_cmd_table which contains function pointers
+to the various command handlers.
+
+Write Command Handlers
+~~~~~~~~~~~~~~~~~~~~~~
+These command handler functions are declared
+with the IB_VERBS_DECLARE_CMD macro in drivers/infiniband/core/uverbs.h. There
+are also extended commands, which are kept in a similar manner in the
+uverbs_ex_cmd_table. The extended commands use 64-bit values in the command
+header, as opposed to the 32-bit values used in the regular command table.
+
+Ioctl system call
+-----------------
+The entry point for the 'ioctl' system call is the ib_uverbs_ioctl() function.
+Unlike write(), ioctl() accepts a 'cmd' parameter, which must have the value
+defined by RDMA_VERBS_IOCTL. More documentation regarding the ioctl numbering
+scheme can be found in: Documentation/ioctl/ioctl-number.txt. The
+command-specific information is passed as a pointer in the 'arg' parameter,
+which is cast as a 'struct ib_uverbs_ioctl_hdr*'.
+
+The way command handler functions (methods) are looked up is more complicated
+than the array index used for write(). Here, the ib_uverbs_cmd_verbs() function
+uses a radix tree to search for the correct command handler. If the lookup
+succeeds, the method is invoked by ib_uverbs_run_method().
+
+Ioctl Command Handlers
+~~~~~~~~~~~~~~~~~~~~~~
+Command handlers (also known as 'methods') for ioctl are declared with the
+UVERBS_HANDLER macro. The handler is registered for use by the
+DECLARE_UVERBS_NAMED_METHOD macro, which binds the name of the handler with its
+attributes. By convention, the methods are implemented in files named with the
+prefix 'uverbs_std_types_'.
+
+Each method can accept a set of parameters called attributes. There are 6
+types of attributes: idr, fd, pointer, enum, const and flags. The idr attribute
+declares an indirect (translated) handle for the method, and
+specifies the object that the method will act upon. The first attribute should
+be a handle to the uobj (ib_uobject) which contains private data. There may be
+0 or more
+additional attributes, including other handles. The 'pointer' attribute must be
+specified as 'in' or 'out', depending on if it is an input from userspace, or
+meant to return a value to userspace.
+
+The method also needs to be bound to an object, which is done with the
+DECLARE_UVERBS_NAMED_OBJECT macro. This macro takes a variable
+number of methods and stores them in an array attached to the object.
+
+Objects are declared using DECLARE_UVERBS_NAMED_OBJECT macro. Most of the
+objects (including pd, mw, cq, etc.) are defined in uverbs_std_types.c,
+and the remaining objects are declared in files that are prefixed with the
+name 'uverbs_std_types_'.
+
+Objects trees are declared using the DECLARE_UVERBS_OBJECT_TREE macro. This
+combines all of the objects.
-- 
2.7.4

Powered by blists - more mailing lists