lkml.org 
[lkml]   [2020]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [EXT] Re: [PATCH v2 0/5] UFS Host Performance Booster (HPB v1.0) driver
Date

>
> Hi, Christoph
> Thanks for your feedback.
>
> > > To avoid touching the traditional SCSI core, the HPB driver in this
> > > series HPB patch chooses to develop under SCSI sub-system layer, and
> > > sits the same layer with UFSHCD. At the same time, to minimize changes
> > > to UFSHCD driver, the HPB driver submits its HPB READ BUFFER and HPB
> > > WRITE BUFFER requests to the scsi
> > > device->request_queueu to execute, rather than that directly go
> > > device->through
> > > raw UPIU request path.
> >
> > This feature is completley broken, and rather dangerous due to feeding
> > "physical" addresses looked up by the host in. I do not think we should
> support
> > something that broken in Linux.
> >
>
> It Is not plain physical address, has been encrypted before loading from UFS
> to
> HPB memory, I think we don't worry about its safety.
>
> > Independent of that using two requests in the I/O path is not going to fly
> either.
> > The whole thing seems like an exercise in benchmarketing.
>
> I agree with you. This is my major concern. I have been thinking about HPB
> implementation in SCSI layer.
> That will let SCSI layer manage HPB by calling UFS helper interface.
> If you don't consider UFS HPB is an idiot design, I want to change in another
> version. Firstly, we really
> want to hear your suggestion.
> Thanks,
>
> //Bean

If indeed this will move forward, please publish your patches as a RFC,
To allow competing approaches to be published as well.

Thanks,
Avri

\
 
 \ /
  Last update: 2020-04-23 10:27    [W:0.199 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site