Hi Bart, On Mon, 2022-04-04 at 14:13 -0700, Bart Van Assche wrote: > On 4/4/22 01:12, Bean Huo wrote: > > Very interested in this design. I'm assuming you're still going to > > continue parsing SCSI commands. Can we also shorten the UFS command > > path? > > > > Meaning we convert block requests directly to UFS UPIU commands? > > instead of like the current one: block request -> CDB -> UPIU. > > Hi Bean, > > Is there any data that shows that the benefits of shortening the UFS > command path outweigh the disadvantages? For performance improvement, according to my test, if we abandon SCSI command parsing, we can get 3%~5% performance improvement. Maybe this is little or no improvement? Yes, reliability issues outweigh this performance improvement. Error handling and UFS probes should also be rebuilt. But most importantly, it makes UFS more scalable. How do you think about adding an immature development driver to drever/staging first? name it driver/staging/lightweight-ufs? > For other SCSI LLDs the cost of > atomic operations and memory barriers in the LLD outweighs the cost > of > the operations in the SCSI core and sd drivers. I'm not sure whether > that's also the case for the UFS driver. > I didn't take this into account, maybe it's not a big deal, since the UFS driver might use its own lock/serialization lock. Kind regards, Bean. > Thanks, > > Bart.
