Re: [PATCH v2 5/5] scsi: ufs: UFS Host Performance Booster(HPB) driver

[Bean Huo <huobean@gmail.com>]

On Mon, 2020-04-27 at 20:36 -0700, Bart Van Assche wrote:
> On 2020-04-26 23:13, Avri Altman wrote:
> > > On 2020-04-25 01:59, Avri Altman wrote:
> > 
> > HPB support is comprised of 4 main duties:
> > 1) Read the device HPB configuration
> > 2) Attend the device's recommendations that are embedded in the
> > sense buffer
> > 3) L2P cache management - This entails sending 2 new scsi commands
> > (opcodes were taken from the vendor pool):
> > 	a. HPB-READ-BUFFER - read L2P physical addresses for a
> > subregion
> > 	b. HPB-WRITE-BUFFER - notify the device that a region is
> > inactive (in host-managed mode)
> > 4) Use HPB-READ: a 3rd new scsi command (again - uses the vendor
> > pool) to perform read operation instead of READ10.  HPB-READ
> > carries both the logical and the physical addresses.
> > 
> > I will let Bean defend the Samsung approach of using a single LLD
> > to attend all 4 duties.
> > 
> > Another approach might be to split those duties between 2 modules:
> >  - A LLD that will perform the first 2 - those can be done only
> > using ufs privet stuff, and 
> >  - another module in scsi mid-layer that will be responsible of L2P
> > cache management,
> >   and HPB-READ command setup.
> > A framework to host the scsi mid-layer module can be the scsi
> > device handler.
> > 
> > The scsi-device-handler infrastructure was added to the kernel
> > mainly to facilitate multiple paths for storage devices.
> > The HPB framework, although far from the original intention of the
> > authors, might as well fit in.
> > In that sense, using READs and HPB_READs intermittently, can be
> > perceived as a multi-path.
> > 
> > Scsi device handlers are also attached to a specific scsi_device
> > (lun).
> > This can serve as the glue linking between the ufs LLD and the
> > device handler which resides in the scsi level.
> > 
> > Device handlers comes with a rich and handy set of APIs & ops,
> > which we can use to support HPB.
> > Specifically we can use it to attach & activate the device handler,
> > only after the ufs driver verified that HPB is supported by both
> > the platform and the device. 
> > 
> > The 2 modules can communicate using the handler_data opaque
> > pointer,
> > and the handler’s set_params op-mode: which is an open protocol
> > essentially,
> > and we can use it to pass the sense buffer in its full or just a
> > parsed version.
> > 
> > Being a scsi mid-layer module, it will not break anything while
> > sending
> > HPB-READ-BUFFER and HPB-WRITE-BUFFER as part of the L2P cache
> > management duties.
> > 
> > Last but not least, the device handler is already hooked in the
> > scsi command setup flow - scsi_setup_fs_cmnd(),
> > So we get the hook into HPB-READ prep_fn for free.   
> >  
> > Later on, we might want to export the L2P cache management logic to
> > user-space.
> > Locating the L2P cache management in scsi mid-layer will enable us
> > to do so, using the scsi-netlink or some other means.
> 
> 
> - Will preparing a SCSI command involve executing a SCSI command? If
> so,
>   how will it be prevented that execution of that internally
> submitted
>   SCSI command triggers a deadlock due to tag exhaustion?
> 
> Thanks,
> 

No, as for the HPB READ, it will replace SCSI READ in SCSI request
executing path in case L2P entry hit in HPB cache. so it still uses the
previously assigned tag.

As for the HPB BUFFER READ and HPB BUFFER WRITE, should beg for a new
tag from hba->cmd_queue.

Bean