On 1/9/23 6:17?PM, Bart Van Assche wrote: > On 1/9/23 17:03, Jens Axboe wrote: >> Because I'm really not thrilled to see the addition of various "is this >> device ordered" all over the place, and now we are getting "is this >> device ordered AND pipelined". Do you see what I mean? It's making >> things _worse_, not better, and we really should be making it better >> rather than pile more stuff on top of it. > > Hi Jens, > > I agree with you that the additional complexity is unfortunate. > > For most zoned storage use cases a queue depth above one is not an > option if the zoned device expects zoned write commands in LBA order. > ATA controllers do not support preserving the command order. > Transports like NVMeOF do not support preserving the command order > either. UFS is an exception. The only use case supported by the UFS > specification is a 1:1 connection between UFS controller and UFS > device with a link with a low BER between controller and device. UFS > controllers must preserve the command order per command queue. I think > this context is well suited for pipelining zoned write commands. But it should not matter, if the scheduler handles it, and requeues are ordered correctly. If the queue depth isn't known at init time, surely we'd get a retry condition on submitting a request if it can't accept another one. That'd trigger a retry, and the retry should be the first one submitted when the device can accept another one. Any setup that handles queue depth > 1 will do just fine at 1 as well. -- Jens Axboe
