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

[Avri Altman]

> 
> On 2020-04-25 01:59, Avri Altman wrote:
> > One last word for the community members that are not into ufs day-to-
> day:
> >
> > HPB implementation made its first public appearance around 2018 as part
> of Google's Pixel3 and some VIVO models.
> > Since then, more and more mobile platforms are publically using HPB:
> Galaxy Note10,
> > Galaxy S20 and VIVO NEX3 (that is already using HPB2.0), some Xiaomi
> models etc.
> >
> > On the other hand, HPB1.0 spec was just recently closed - not even as part
> of UFS3.1,
> > but only after - about 2 months ago. The industry is rushing forward, we've
> seen this many times.
> >
> > The fact is that HPB is here to stay - either as a horde of out-of-tree
> implementations,
> > or as a standard acceptable mainline driver.
> 
> Hi Avri,
> 
> Thanks for the additional clarification. I think we need HPB support in
> the upstream kernel. A possible approach is to start a discussion about
> how to integrate HPB support in the upstream kernel and to defer posting
> new implementations until agreement about an approach has been achieved.
> Is there e.g. an alternative for avoiding deadlocks other than using the
> blk-mq reserved tag feature for the commands that manage the L2P tables?

Ok then.
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.

Thanks,
Avri