From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B68613403EC for ; Tue, 19 May 2026 13:39:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779197942; cv=none; b=c2i1qPeVimuLM9HoFkl+/Zl+270Fod3p/bMx+pYFRH6CQx2BU6XIzeyuzAL4N4dntQPCvojhhUYSsKjQsTyi1LZEpX1nlozs65IWo76X04azb4qKqM4LlvDTqvsPpyF7O41dyoECoVsEGWluHM+K4I8hlIAyfeF9JpUOUa4ryXo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779197942; c=relaxed/simple; bh=j6kmObGSeK2ZeC0WaITxKLJu1tgkBBxfEV4F1cdLG6o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rH0dTI8fq+PGkDyu5AKQAA6lfQpHBYHWFweZiTy5n741xg80cP+VBxP+dDTDR1fun7YXvg0s4resJeA5+Nqu8JG5VbObZ135g+qmB1ITyby8jzsvDEbWYVNUSGTCHJtJLQl+4qW7BWSI0u/AM7fD22tCD0Xp8+c/zGa52OkPnew= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=n7wADz+c; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="n7wADz+c" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC58BC2BCB3; Tue, 19 May 2026 13:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779197942; bh=j6kmObGSeK2ZeC0WaITxKLJu1tgkBBxfEV4F1cdLG6o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n7wADz+cGnL6cRc7KnJNWRHBvIqRVqXDZdxWJwUjPaccBss9axAqf95xwZaqeXrZ/ V/T+7YWIvzhYVW8AkR+hOlcInpcgSEo7xZRmnjlf9kExRldrzPB54e44zSHzKGgAig RxVGe8r84T4Vas3Aqng5TeAHpCvNArL1qpUtoPks/bVrtBa9abaHX3CH8AAkH5oMZ3 mv84dsE+RwQqMChQTtesRY/VaqDxyM87KgCLYm0P6wwPmX22cgLwmowK6UtqrdXkf1 SYZb9U9K2cxD2FOlh4CgIsmu/B1iDxLl06Ds6r4qGieBgDvzOv34xwY/v1zmhbKTse UEwDuy7FKlGGg== Date: Tue, 19 May 2026 16:38:57 +0300 From: Leon Romanovsky To: Yonatan Nachum Cc: jgg@nvidia.com, linux-rdma@vger.kernel.org, mrgolin@amazon.com, sleybo@amazon.com, matua@amazon.com, gal.pressman@linux.dev, Firas Jahjah Subject: Re: [PATCH for-next v2 2/2] RDMA/efa: Add AH cache handling on create and destroy AH Message-ID: <20260519133857.GW33515@unreal> References: <20260512061121.2177521-1-ynachum@amazon.com> <20260512061121.2177521-3-ynachum@amazon.com> Precedence: bulk X-Mailing-List: linux-rdma@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260512061121.2177521-3-ynachum@amazon.com> On Tue, May 12, 2026 at 06:11:21AM +0000, Yonatan Nachum wrote: > On create AH, first check if the AH cache entry already exists and if > so, returns the already stored AH number. If the entry doesn't exist, > the driver creates it and calls the device to create the AH. A per-entry > mutex serializes concurrent device commands on the same AH cache entry, > ensuring only one thread issues the device create while others wait and > reuse the result. If the device create fails, the entry remains > uninitialized so subsequent threads calls can create the AH. > > On destroy AH, the refcount is checked and if it's the last reference, > the driver issues the device destroy command while holding the entry > mutex. The entry remains in the hashtable during destroy to allow > concurrent create threads to find it and wait on the entry mutex, > preventing create-before-destroy races on the device. After the device > destroy completes, the entry is either recycled if new users arrived or > removed and freed. > > Reviewed-by: Firas Jahjah > Reviewed-by: Michael Margolin > Signed-off-by: Yonatan Nachum > --- > drivers/infiniband/hw/efa/efa_ah_cache.c | 124 +++++++++++++++++++++++ > drivers/infiniband/hw/efa/efa_ah_cache.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 +- > 5 files changed, 162 insertions(+), 4 deletions(-) <...> > + > +/** > + * efa_ah_cache_put - Release the final reference to an AH cache entry > + * @ah_cache: AH cache > + * @entry: AH cache entry > + * > + * Decrement the refcount. If it reaches zero, the entry is removed from the > + * hashtable and freed. Otherwise, the entry is kept for reuse. > + * > + * Called after the device destroy completes or on a failed create to release > + * the caller's reference. > + */ > +void efa_ah_cache_put(struct efa_ah_cache *ah_cache, struct efa_ah_cache_entry *entry) > +{ > + mutex_lock(&ah_cache->lock); > + if (!refcount_dec_and_test(&entry->refcount)) { > + mutex_unlock(&ah_cache->lock); > + return; > + } > + > + rhashtable_remove_fast(&ah_cache->hashtable, &entry->linkage, ah_cache_params); > + mutex_unlock(&ah_cache->lock); > + > + mutex_destroy(&entry->lock); > + kvfree(entry); > +} This pattern looks very similar to kref_put_mutex(). Thanks