Re: [PATCH 00/29] UFS patches for kernel v5.19

[Bean Huo <huobean@gmail.com>]

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.