All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Peng Fan <peng.fan@oss.nxp.com>
Cc: Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	"Joerg Roedel (AMD)" <joro@8bytes.org>,
	Jean-Philippe Brucker <jpb@kernel.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	<linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>,
	<linux-kernel@vger.kernel.org>, Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH RFC v2 1/4] iommu/arm-smmu-v3: Convert streams from RB tree to XArray
Date: Tue, 22 Sep 2026 09:56:52 -0700	[thread overview]
Message-ID: <arKzVL3PA/d2o8lF@nvidia.com> (raw)
In-Reply-To: <arKK9+M85xeknRa9@shlinux89>

On Tue, Sep 22, 2026 at 10:04:39PM +0800, Peng Fan wrote:
> >... and slightly mentions "simplifies". Maybe it should write about
> >why this is necessary and how xarray would simplify vs RB tree?
> 
> Jean had a comment that "maybe simplify the driver first by moving to a xarray",
> see [1] [2].
> 
> [1] https://lore.kernel.org/linux-iommu/20230518130459.GA2587493@myrica/
> [2] https://lore.kernel.org/linux-iommu/ecb3725c-27c4-944b-b42c-f4e293521f94@arm.com/#t

You should have put a suggested-by tag and likely one of the links
as well.

With that being said, I don't see the reasoning in those emails very
convincing either. I don't dislike xarray. Yet in this series, there
seems no compelling reason on switching RB tree to xarray.

> A subsequent patch needs to look up an existing stream by SID and
> then decide to share it rather than reject it - two separate
> operations. The RB tree's rb_find_add() fuses lookup and insertion
> atomically: it either inserts or returns the collision, making
> "find, then conditionally share" impossible without restructuring.
> XArray's xa_load() and xa_store() are independent operations that
> naturally support this pattern.

If you avoid duplicated stream structures as I suggested in PATCH-2,
there is no need of that, since you would only insert once to the RB
tree.

Nicolin

  reply	other threads:[~2026-09-22 16:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 11:34 [PATCH RFC v2 0/4] iommu/arm-smmu-v3: Support shared Stream IDs Peng Fan (OSS)
2026-09-21 11:35 ` [PATCH RFC v2 1/4] iommu/arm-smmu-v3: Convert streams from RB tree to XArray Peng Fan (OSS)
2026-09-21 19:24   ` Nicolin Chen
2026-09-22 14:04     ` Peng Fan
2026-09-22 16:56       ` Nicolin Chen [this message]
2026-09-21 12:38 ` [PATCH RFC v2 2/4] iommu/arm-smmu-v3: Support shared SIDs in insert/remove_master Peng Fan (OSS)
2026-09-21 23:15   ` Nicolin Chen
2026-09-22 14:13     ` Peng Fan
2026-09-22 15:52       ` Robin Murphy
2026-09-22 17:47         ` Nicolin Chen
2026-09-21 12:40 ` [PATCH RFC v2 3/4] iommu/arm-smmu-v3: Group aliasing devices into the same IOMMU group Peng Fan (OSS)
2026-09-21 12:41 ` [PATCH RFC v2 4/4] iommu/arm-smmu-v3: Wire up shared-SID STE ordering and feature gating Peng Fan (OSS)

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=arKzVL3PA/d2o8lF@nvidia.com \
    --to=nicolinc@nvidia.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=jpb@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peng.fan@nxp.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /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.