Re: [PATCH for-next v2 0/2] RDMA/efa: Add AH cache for AH reuse

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, May 12, 2026 at 06:11:19AM +0000, Yonatan Nachum wrote:
> Changelog:
> v2:
>  * Zero-initialize AH cache key on cache lookup.
> v1: https://lore.kernel.org/all/20260510083035.458081-1-ynachum@amazon.com/
> 
> -------------------------------------------------------------------------
> New EFA devices don't support the creation of multiple AHs to the same
> remote on the same PD. To overcome this limitation, introduce an AH
> cache that manages AH reuse transparently.
> 
> The cache uses an rhashtable keyed by (PD, GID) to track active address
> handles with refcounts. On create AH, the driver returns an existing AH
> number if one is already cached, or creates a new one and caches it. On
> destroy AH, the driver only issues the device destroy command when the
> last reference is dropped.
> 
> A per-entry mutex serializes concurrent device commands on the same
> cache entry, preventing create-before-destroy races on the device.
> 
> Yonatan Nachum (2):
>   RDMA/efa: Add initialization of AH cache rhashtable
>   RDMA/efa: Add AH cache handling on create and destroy AH
> 
>  drivers/infiniband/hw/efa/Makefile       |   4 +-
>  drivers/infiniband/hw/efa/efa_ah_cache.c | 154 +++++++++++++++++++++++
>  drivers/infiniband/hw/efa/efa_ah_cache.h |  41 ++++++
>  drivers/infiniband/hw/efa/efa_com.c      |  12 +-
>  drivers/infiniband/hw/efa/efa_com.h      |   5 +-
>  drivers/infiniband/hw/efa/efa_com_cmd.c  |  27 ++++
>  drivers/infiniband/hw/efa/efa_com_cmd.h  |   1 +
>  drivers/infiniband/hw/efa/efa_verbs.c    |   9 +-
>  8 files changed, 245 insertions(+), 8 deletions(-)
>  create mode 100644 drivers/infiniband/hw/efa/efa_ah_cache.c
>  create mode 100644 drivers/infiniband/hw/efa/efa_ah_cache.h

The sashiko comments seem quite serious, please fix some of them up..

https://sashiko.dev/#/patchset/20260512061121.2177521-1-ynachum%40amazon.com

I would not do the GFP_ACCOUNT suggestion, we don't do that in RDMA
(though perhaps we should)

The races look right, the mis-use of the API looks right, and IDK
about the leak on cache_destroy, either clean it up or stick a WARN_ON
that it must be empty.

Jason