All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Bob Pearson <rpearsonhpe@gmail.com>
Cc: jgg@nvidia.com, zyjzyj2000@gmail.com, linux-rdma@vger.kernel.org,
	jhack@hpe.com
Subject: Re: [PATCH for-next 2/2] RDMA/rxe: Enable rcu locking of indexed objects
Date: Sun, 23 Jul 2023 18:00:50 +0300	[thread overview]
Message-ID: <20230723150050.GA60079@unreal> (raw)
In-Reply-To: <4450c401-2a02-d66d-5615-22f65e291a04@gmail.com>

On Wed, Jul 19, 2023 at 11:43:30AM -0500, Bob Pearson wrote:
> On 7/19/23 02:49, Leon Romanovsky wrote:
> > On Tue, Jul 18, 2023 at 12:59:44PM -0500, Bob Pearson wrote:
> >> Make rcu_read locking of critical sections with the indexed
> >> verbs objects be protected from early freeing of those objects.
> >> The AH, QP, MR and MW objects are looked up from their indices
> >> contained in received packets or WQEs during I/O processing.
> >> Make these objects be freed using kfree_rcu to avoid races.
> > 
> > Sorry, how use of RCU avoid races?
> > 
> > Thanks
> 
> The races are between destroy/deallocate/dereg verbs API calls and packets arriving or completing send
> or deferred processing of wqes. Packets and wqes contain indices/keys/numbers that refer to objects.
> The rxe driver maintains xarrays for each type of object that allow to lookup the address of the object
> from its index and then take a reference to protect the pointer. The destroy verbs defer completion
> until the reference count falls to zero and then removes the entry in the xarray. These operations
> need to be atomic. One alternative is to use spinlocks to protect them but that places a load on
> performance under heavy load which is typically dominated by the lookup function since objects tend
> to have a long lifetime. rcu readlocks are a better alternative but depend on the deferred destruction
> of the objects used in the rcu critical section. 

You rarely can replace locks with RCU without careful design changes.

Thanks

  reply	other threads:[~2023-07-23 15:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-18 17:59 [PATCH for-next 0/2] Enable rcu locking of verbs objects Bob Pearson
2023-07-18 17:59 ` [PATCH for-next 1/2] RDMA/core: Support drivers use of rcu locking Bob Pearson
2023-08-09 19:10   ` Jason Gunthorpe
2023-07-18 17:59 ` [PATCH for-next 2/2] RDMA/rxe: Enable rcu locking of indexed objects Bob Pearson
2023-07-19  5:38   ` Zhu Yanjun
2023-07-19 14:34     ` Bob Pearson
2023-07-19  7:49   ` Leon Romanovsky
2023-07-19 16:43     ` Bob Pearson
2023-07-23 15:00       ` Leon Romanovsky [this message]
2023-08-09 19:17   ` Jason Gunthorpe

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=20230723150050.GA60079@unreal \
    --to=leon@kernel.org \
    --cc=jgg@nvidia.com \
    --cc=jhack@hpe.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=rpearsonhpe@gmail.com \
    --cc=zyjzyj2000@gmail.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.