From: Christoph Hellwig <hch@lst.de>
To: Nick Chan <towinchenmi@gmail.com>
Cc: Sven Peter <sven@kernel.org>, Janne Grunau <j@jannau.net>,
Neal Gompa <neal@gompa.dev>, Keith Busch <kbusch@kernel.org>,
Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 1/2] nvme-apple: Only limit admin queue tag space when with Linear SQ is present
Date: Wed, 10 Jun 2026 07:11:46 +0200 [thread overview]
Message-ID: <20260610051146.GA559@lst.de> (raw)
In-Reply-To: <20260606-prevent-tag-collision-t8015-v1-1-93ccf4eca550@gmail.com>
On Sat, Jun 06, 2026 at 09:25:25PM +0800, Nick Chan wrote:
> Apple NVMe controllers require tags of pending commands to not be shared
> across admin and IO queues. However, on Apple A11 without linear SQ, it is
> not possible for either queue to skip over some tags and must go from 0 to
> the configured maximum before wrapping around.
>
> As a result, in order to prevent tag collision, dynamic tag reservation
> while a command is in-flight becomes necessary. In this context, there is
> no reason to limit the admin queue's tag space, as it is not helpful in
> preventing tag collision.
I'm not really into these Apple specific, but what does
"dynamic tag reservation" mean here?
next prev parent reply other threads:[~2026-06-10 5:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-06 13:25 [PATCH 0/2] nvme-apple: Prevent tag collision across queues on Apple A11 Nick Chan
2026-06-06 13:25 ` [PATCH 1/2] nvme-apple: Only limit admin queue tag space when with Linear SQ is present Nick Chan
2026-06-10 5:11 ` Christoph Hellwig [this message]
2026-06-10 11:15 ` Nick Chan
2026-06-06 13:25 ` [PATCH 2/2] nvme-apple: Prevent tag collision across queues even if tag space is shared Nick Chan
2026-06-06 14:29 ` David Laight
2026-06-06 15:51 ` Nick Chan
2026-06-06 15:08 ` Nick Chan
2026-06-06 16:12 ` Sven Peter
2026-06-06 16:46 ` Nick Chan
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=20260610051146.GA559@lst.de \
--to=hch@lst.de \
--cc=asahi@lists.linux.dev \
--cc=axboe@kernel.dk \
--cc=j@jannau.net \
--cc=kbusch@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=neal@gompa.dev \
--cc=sagi@grimberg.me \
--cc=stable@vger.kernel.org \
--cc=sven@kernel.org \
--cc=towinchenmi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox