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

[Leon Romanovsky <leon@kernel.org>]

On Thu, Feb 26, 2026 at 07:39:08PM +0200, Edward Srouji wrote:
> 
> 
> 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@nvidia.com>
> > > 
> > > 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@nvidia.com>
> > > Reviewed-by: Yishai Hadas <yishaih@nvidia.com>
> > > Signed-off-by: Edward Srouji <edwards@nvidia.com>
> > > ---
> > >   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...

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.

> 
> > Thanks
>