All of lore.kernel.org
 help / color / mirror / Atom feed
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


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