Documentation/infiniband/core_locking.rst

Source file repositories/reference/linux-study-clean/Documentation/infiniband/core_locking.rst

File Facts

System
Linux kernel
Corpus path
Documentation/infiniband/core_locking.rst
Extension
.rst
Size
4193 bytes
Lines
117
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

===========================
InfiniBand Midlayer Locking
===========================

  This guide is an attempt to make explicit the locking assumptions
  made by the InfiniBand midlayer.  It describes the requirements on
  both low-level drivers that sit below the midlayer and upper level
  protocols that use the midlayer.

Sleeping and interrupt context
==============================

  With the following exceptions, a low-level driver implementation of
  all of the methods in struct ib_device may sleep.  The exceptions
  are any methods from the list:

    - create_ah
    - modify_ah
    - query_ah
    - destroy_ah
    - post_send
    - post_recv
    - poll_cq
    - req_notify_cq

  which may not sleep and must be callable from any context.

  The corresponding functions exported to upper level protocol
  consumers:

    - rdma_create_ah
    - rdma_modify_ah
    - rdma_query_ah
    - rdma_destroy_ah
    - ib_post_send
    - ib_post_recv
    - ib_req_notify_cq

  are therefore safe to call from any context.

  In addition, the function

    - ib_dispatch_event

  used by low-level drivers to dispatch asynchronous events through
  the midlayer is also safe to call from any context.

Reentrancy
----------

  All of the methods in struct ib_device exported by a low-level
  driver must be fully reentrant.  The low-level driver is required to
  perform all synchronization necessary to maintain consistency, even
  if multiple function calls using the same object are run
  simultaneously.

  The IB midlayer does not perform any serialization of function calls.

  Because low-level drivers are reentrant, upper level protocol
  consumers are not required to perform any serialization.  However,
  some serialization may be required to get sensible results.  For
  example, a consumer may safely call ib_poll_cq() on multiple CPUs
  simultaneously.  However, the ordering of the work completion
  information between different calls of ib_poll_cq() is not defined.

Callbacks
---------

  A low-level driver must not perform a callback directly from the
  same callchain as an ib_device method call.  For example, it is not

Annotation

Implementation Notes