From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Christoph Hellwig <hch@lst.de>, Bart Van Assche <bvanassche@acm.org>
Cc: Ming Lei <ming.lei@redhat.com>, Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
Jan Kara <jack@suse.cz>,
Johannes Thumshirn <johannes.thumshirn@wdc.com>
Subject: Re: [PATCH 2/2] block: Split and submit bios in LBA order
Date: Thu, 23 Mar 2023 19:28:12 +0900 [thread overview]
Message-ID: <acd13f8c-6cbe-a14d-e3b4-645d62811cec@opensource.wdc.com> (raw)
In-Reply-To: <20230323082604.GC21977@lst.de>
On 3/23/23 17:26, Christoph Hellwig wrote:
> On Tue, Mar 21, 2023 at 07:36:12AM -0700, Bart Van Assche wrote:
>> The UFSHCI specification is very clear about the requirement that UFS host
>> controllers must process SCSI commands in order if host software sets one
>> bit at a time in the UFSHCI 3.0 doorbell register: "For Task Management
>> Requests and Transfer Requests, software may issue multiple commands at a
>> time, and may issue new commands before previous commands have completed.
>> When software sets the corresponding doorbell register, the Task Management
>> Requests and Transfer Requests automatically get a time stamp with their
>> issue time. The commands within a command list (Task Management List or
>> Transfer Request List) shall be processed in
>> the order of their time stamps, starting from the oldest time stamp. In the
>> case multiple commands from the same list have the same time stamp, they
>> shall be processed in the order of their command list index,
>> starting from the lowest index."
>
> But we can't write Linux software just for UFS. We have no sensible
> ordering guarantee anywhere else.
>
>> Damien and Jens agree about introducing an additional hardware queue for
>> preserving the order of zoned writes as one can see here:
>> https://lore.kernel.org/linux-block/ed255a4a-a0da-a962-2da4-13321d0a75c5@kernel.dk/
>>
>> In our tests pipelining zoned writes (REQ_OP_WRITE) works fine as long as
>> the UFS error handler is not activated. After the UFS error handler has
>> been scheduled and before the SCSI host state is changed into
>> SHOST_RECOVERY, the UFS host controller driver responds with
>> SCSI_MLQUEUE_HOST_BUSY. I'm still working on a solution for the reordering
>> caused by this mechanism.
>
> We'll still need REQ_OP_ZONE_APPEND as the actual file system fast path
> interface. For a low-end device like UFS the sd.c emulation might be
> able to take advantage of the above separate queue as an implementation
> detail.
For the zone append emulation, the write locking is done by sd.c and the upper
layer does not restrict to one append per zone. So we actually could envision a
UFS version of the sd write locking calls that is optimized for the device
capabilities and we can keep a common upper layer (which is preferable in my
opinion).
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2023-03-23 10:32 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 19:59 [PATCH 0/2] Submit split bios in LBA order Bart Van Assche
2023-03-17 19:59 ` [PATCH 1/2] block: Split blk_recalc_rq_segments() Bart Van Assche
2023-03-18 6:38 ` Christoph Hellwig
2023-03-17 19:59 ` [PATCH 2/2] block: Split and submit bios in LBA order Bart Van Assche
2023-03-17 22:28 ` Jan Kara
2023-03-18 6:33 ` Christoph Hellwig
2023-03-17 23:38 ` Ming Lei
2023-03-17 23:45 ` Bart Van Assche
2023-03-20 23:28 ` Ming Lei
2023-03-20 23:32 ` Bart Van Assche
2023-03-21 0:44 ` Ming Lei
2023-03-21 1:46 ` Damien Le Moal
2023-03-21 2:17 ` Ming Lei
2023-03-21 3:24 ` Damien Le Moal
2023-03-21 8:00 ` Ming Lei
2023-03-21 8:51 ` Damien Le Moal
2023-03-21 9:09 ` Christoph Hellwig
2023-03-21 9:50 ` Damien Le Moal
2023-03-21 5:55 ` Christoph Hellwig
2023-03-21 14:36 ` Bart Van Assche
2023-03-23 8:26 ` Christoph Hellwig
2023-03-23 10:28 ` Damien Le Moal [this message]
2023-03-23 16:27 ` Bart Van Assche
2023-03-23 22:53 ` Damien Le Moal
2023-03-24 16:55 ` Bart Van Assche
2023-03-25 2:00 ` Damien Le Moal
2023-03-25 16:31 ` Bart Van Assche
2023-03-26 1:45 ` Damien Le Moal
2023-03-26 23:45 ` Christoph Hellwig
2023-03-27 21:06 ` Bart Van Assche
2023-03-27 23:43 ` Christoph Hellwig
2023-04-06 20:30 ` Bart Van Assche
2023-03-27 21:20 ` Bart Van Assche
2023-03-18 6:42 ` Christoph Hellwig
2023-03-18 6:29 ` [PATCH 0/2] Submit split " Christoph Hellwig
2023-03-20 17:22 ` Bart Van Assche
2023-03-20 21:06 ` Khazhy Kumykov
2023-03-23 8:27 ` Christoph Hellwig
2023-03-24 17:05 ` Bart Van Assche
2023-03-25 2:15 ` Damien Le Moal
2023-03-26 23:42 ` Christoph Hellwig
2023-03-26 23:44 ` Christoph Hellwig
2023-04-06 20:32 ` Bart Van Assche
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=acd13f8c-6cbe-a14d-e3b4-645d62811cec@opensource.wdc.com \
--to=damien.lemoal@opensource.wdc.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jaegeuk@kernel.org \
--cc=johannes.thumshirn@wdc.com \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.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;
as well as URLs for NNTP newsgroup(s).