On Thu, Feb 26, 2026 at 07:39:08PM +0200, Edward Srouji wrote:

On 2/26/2026 4:11 PM, Leon Romanovsky wrote:

quoted

External email: Use caution opening links or attachments


On Thu, Feb 26, 2026 at 03:52:07PM +0200, Edward Srouji wrote:

quoted

From: Michael Guralnik <redacted>

Add a generic Fast Registration Memory Region pools mechanism to allow
drivers to optimize memory registration performance.
Drivers that have the ability to reuse MRs or their underlying HW
objects can take advantage of the mechanism to keep a 'handle' for those
objects and use them upon user request.
We assume that to achieve this goal a driver and its HW should implement
a modify operation for the MRs that is able to at least clear and set the
MRs and in more advanced implementations also support changing a subset
of the MRs properties.

The mechanism is built using an RB-tree consisting of pools, each pool
represents a set of MR properties that are shared by all of the MRs
residing in the pool and are unmodifiable by the vendor driver or HW.

The exposed API from ib_core to the driver has 4 operations:
Init and cleanup - handles data structs and locks for the pools.
Push and pop - store and retrieve 'handle' for a memory registration
or deregistrations request.

The FRMR pools mechanism implements the logic to search the RB-tree for
a pool with matching properties and create a new one when needed and
requires the driver to implement creation and destruction of a 'handle'
when pool is empty or a handle is requested or is being destroyed.

Later patch will introduce Netlink API to interact with the FRMR pools
mechanism to allow users to both configure and track its usage.
A vendor wishing to configure FRMR pool without exposing it or without
exposing internal MR properties to users, should use the
kernel_vendor_key field in the pools key. This can be useful in a few
cases, e.g, when the FRMR handle has a vendor-specific un-modifiable
property that the user registering the memory might not be aware of.

Signed-off-by: Michael Guralnik <redacted>
Reviewed-by: Yishai Hadas <yishaih@nvidia.com>
Signed-off-by: Edward Srouji <redacted>
---
  drivers/infiniband/core/Makefile     |   2 +-
  drivers/infiniband/core/frmr_pools.c | 319 +++++++++++++++++++++++++++++++++++
  drivers/infiniband/core/frmr_pools.h |  48 ++++++
  include/rdma/frmr_pools.h            |  37 ++++
  include/rdma/ib_verbs.h              |   8 +
  5 files changed, 413 insertions(+), 1 deletion(-)

<...>

quoted

+// SPDX-License-Identifier: GPL-2.0-only

<...>

quoted

+EXPORT_SYMBOL(ib_frmr_pools_init);

It is odd to see these two lines together. Either update the SPDX license to
'GPL-2.0 OR Linux-OpenIB', as we do for uverbs, and keep EXPORT_SYMBOL() as is,
or keep the current SPDX-License-Identifier and switch to EXPORT_SYMBOL_GPL().

Ugh, I missed that.
BTW, we already have the same inconsistency in other core files such as
cq.c, mr_pools.c, rw.c, and more...

These files are intentionally licensed as GPL-2. They are intended for
in-kernel verbs users (ULPs) and are internal to the kernel.

Let's replace the license with 'GPL-2.0 OR Linux-OpenIB' to stay consistent
with the rest of the RDMA core, where all exported symbols are used under
the dual license.
Do you need me to send v5 for this?

No, I'll fix.

quoted

Thanks