Message ID | 20231114211804.1449162-1-bvanassche@acm.org (mailing list archive) |
---|---|
Headers | show |
Series | Improve write performance for zoned UFS devices | expand |
As this keeps getting reposted: I still think it is a very bad idea to add this amount of complexity to the SCSI code, for a model that can't work for the general case and diverges from the established NVMe model. So I do not thing we should support this.
On 11/26/23 23:09, Christoph Hellwig wrote: > I still think it is a very bad idea to add this amount of complexity to > the SCSI code, for a model that can't work for the general case and > diverges from the established NVMe model. Hi Christoph, Here is some additional background information: * UFS vendors prefer the SCSI command set because they combine it with the M-PHY transport layer. This combination is more power efficient than NVMe over PCIe. According to the information I have available power consumption in the M-PHY hibernation state is lower than in the PCIe L2 state. I have not yet heard about any attempts to combine the NVMe command set with the M-PHY transport layer. Even if this would be possible, it would fragment the mobile storage market. This would increase the price of mobile storage devices which is undesirable. * I think that the "established NVMe model" in your email refers to the NVMe zone append command. As you know there is no zone append in the SCSI ZBC standard. * Using the software implementation of REQ_OP_ZONE_APPEND in drivers/scsi/sd_zbc.c is not an option. REQ_OP_ZONE_APPEND commands are serialized by that implementation. This serialization is unavoidable because a SCSI device may respond with a unit attention condition to any SCSI command. Hence, even if REQ_OP_ZONE_APPEND commands are submitted in order, these may be executed out-of-order. We do not want any serialization of SCSI commands because this has a significant negative performance impact on IOPS for UFS devices. The latest UFS devices support more than 300 K IOPS. * Serialization in the I/O scheduler of zoned writes also reduces IOPS more than what is acceptable. Hence the approach of this patch series to support pipelining of zoned writes even if no I/O scheduler has been configured. I think the amount of complexity introduced by this patch series in the SCSI core is reasonable. No new states are introduced in the SCSI core. A single call to a function that reorders pending SCSI commands is introduced in the SCSI error handler (scsi_call_prepare_resubmit()). Thanks, Bart.
On Mon, Nov 27, 2023 at 11:35:48AM -0800, Bart Van Assche wrote:
> Here is some additional background information:
I know the background. I also know that JEDEC did all this aginst
better judgement and knowing the situation. We should not give them
their carrot after they haven't even been interested in engaging.
On 11/28/23 04:53, Christoph Hellwig wrote: > I know the background. I also know that JEDEC did all this aginst > better judgement and knowing the situation. We should not give them > their carrot after they haven't even been interested in engaging. That statement is overly negative. The JEDEC Zoned Storage for UFS standard has been published last week [1]. It can be downloaded by anyone for free after having created a JEDEC account, which is also free. As one can see in this standard, nothing excludes using a zone append command. Once T10 standardizes a zone append command, it can be implemented by UFS vendors. However, I do not know whether T10 plans to standardize a zone append command. Bart. [1] https://www.jedec.org/system/files/docs/JESD220-5.pdf