From: Leon Romanovsky <leon@kernel.org>
To: Yonatan Nachum <ynachum@amazon.com>
Cc: jgg@nvidia.com, linux-rdma@vger.kernel.org, mrgolin@amazon.com,
sleybo@amazon.com, matua@amazon.com, gal.pressman@linux.dev
Subject: Re: [PATCH for-next v4 0/2] RDMA/efa: Add AH cache for AH reuse
Date: Tue, 16 Jun 2026 20:50:33 +0300 [thread overview]
Message-ID: <20260616175033.GQ327369@unreal> (raw)
In-Reply-To: <20260614071229.GA29713@dev-dsk-ynachum-1b-aa121316.eu-west-1.amazon.com>
On Sun, Jun 14, 2026 at 07:12:29AM +0000, Yonatan Nachum wrote:
> On Mon, Jun 08, 2026 at 07:16:18AM +0000, Yonatan Nachum wrote:
> > Changelog:
> > v4:
> > * Use kzalloc_obj for AH cache entry allocation instead of kzalloc
> > v3: https://lore.kernel.org/all/20260607161753.1607559-1-ynachum@amazon.com/
> > * Address Sashiko comments in:
> > https://sashiko.dev/#/patchset/20260512061121.2177521-1-ynachum%40amazon.com
> > v2: https://lore.kernel.org/all/20260512061121.2177521-1-ynachum@amazon.com/
> > * 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 | 163 +++++++++++++++++++++++
> > drivers/infiniband/hw/efa/efa_ah_cache.h | 42 ++++++
> > drivers/infiniband/hw/efa/efa_com.c | 12 +-
> > drivers/infiniband/hw/efa/efa_com.h | 3 +
> > drivers/infiniband/hw/efa/efa_com_cmd.c | 73 +++++++---
> > drivers/infiniband/hw/efa/efa_com_cmd.h | 1 +
> > drivers/infiniband/hw/efa/efa_verbs.c | 9 +-
> > 8 files changed, 281 insertions(+), 26 deletions(-)
> > create mode 100644 drivers/infiniband/hw/efa/efa_ah_cache.c
> > create mode 100644 drivers/infiniband/hw/efa/efa_ah_cache.h
> >
> > --
> > 2.50.1
> >
>
> Hi, kind reminder.
> This series blocks merging EFAv4 device ID and we would want it to land
> for the next merge window if possible.
It is not possible.
The use of entry->lock together with a refcount and an "initialize"
flag suggests that the refcount is not being used correctly.
I would expect a single ah_cache lock, with the refcount tracking the
number of users of the entry.
Thanks.
>
> I reviewed the last Sashiko comment and it's not relevant since on
> destroy AH failure, we keep the entry in the hashtable.
>
> Thanks
>
next prev parent reply other threads:[~2026-06-16 17:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 7:16 [PATCH for-next v4 0/2] RDMA/efa: Add AH cache for AH reuse Yonatan Nachum
2026-06-08 7:16 ` [PATCH for-next v4 1/2] RDMA/efa: Add initialization of AH cache rhashtable Yonatan Nachum
2026-06-08 7:16 ` [PATCH for-next v4 2/2] RDMA/efa: Add AH cache handling on create and destroy AH Yonatan Nachum
2026-06-14 7:12 ` [PATCH for-next v4 0/2] RDMA/efa: Add AH cache for AH reuse Yonatan Nachum
2026-06-16 17:50 ` Leon Romanovsky [this message]
2026-06-16 19:31 ` Yonatan Nachum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260616175033.GQ327369@unreal \
--to=leon@kernel.org \
--cc=gal.pressman@linux.dev \
--cc=jgg@nvidia.com \
--cc=linux-rdma@vger.kernel.org \
--cc=matua@amazon.com \
--cc=mrgolin@amazon.com \
--cc=sleybo@amazon.com \
--cc=ynachum@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.