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:12 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 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.