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. Hi Avri, I'm not sure that I agree that HPB can be perceived as multi-path. Anyway, the above approach sounds interesting to me. A few questions though: - The only in-tree caller of scsi_dh_attach() I am aware of exists in the dm-mpath driver. I think that call is triggered by multipathd. I don't think that it is acceptable to require that multipathd is running to use the UFS HPB functionality. What is the plan for attaching the UFS device handler to UFS devices? - 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, Bart.
