Re: [PATCH rdma-next v4 02/11] IB/core: Introduce FRMR pools

[Edward Srouji]

On 2/26/2026 4:11 PM, Leon Romanovsky wrote:
> External email: Use caution opening links or attachments
>
>
> On Thu, Feb 26, 2026 at 03:52:07PM +0200, Edward Srouji wrote:
> > From: Michael Guralnik <michaelgur@xxxxxxxxxx>
> >
> > 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 <michaelgur@xxxxxxxxxx>
> > Reviewed-by: Yishai Hadas <yishaih@xxxxxxxxxx>
> > Signed-off-by: Edward Srouji <edwards@xxxxxxxxxx>
> > ---
> >   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(-)
>
> <...>
>
> > +// SPDX-License-Identifier: GPL-2.0-only
>
> <...>
>
> > +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...
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?

> Thanks