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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BYAPR04MB4629393BA60AF5E5898FB304FCAA0@BYAPR04MB4629.namprd04.prod.outlook.com>
Date:   Thu, 30 Apr 2020 07:23:40 +0000
From:   Avri Altman <Avri.Altman@....com>
To:     Bean Huo <huobean@...il.com>, Bart Van Assche <bvanassche@....org>,
        "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
        "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "stanley.chu@...iatek.com" <stanley.chu@...iatek.com>,
        "beanhuo@...ron.com" <beanhuo@...ron.com>,
        "tomas.winkler@...el.com" <tomas.winkler@...el.com>,
        "cang@...eaurora.org" <cang@...eaurora.org>
CC:     "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 5/5] scsi: ufs: UFS Host Performance Booster(HPB)
 driver

Hi Bean,

> > By now we've read the device HPB configuration, and we are ready  to
> > attach a scsi device to our HPB luns.  A perfect timing might be
> > while
> > scsi is performing its .slave_alloc() or .slave_configure().
> >
> 
> hi, Avri
> That means HPB memory allocation done in .scan_finished() ?
The specifics of this feature are yet to be determined.

Among those, yes - we need to discuss how to handle the memory allocation.
Statically allocating the required cache for the entire max-active-subregions,
Which may sum-up to a hundreds of MB, has its obvious downsize. 
We need to discuss this further.

> and sd_init_command() needs to change as well, add a new request
> type REQ_OP_HPB_READ?
Again, this is an implementation issue.
We need to figure it out in the sequel.
E.g. we might want to make use of the combination of a valid handler and blk_op_is_private.

I think it would be more constructive, if we can decide first on the module layout,
And figure out the other details as we go?

Can you provide the pros and cons for the Samsung approach -
implementing all HPB functionalities using a single LLD?

Thanks,
Avri

> 
> 
> Bean
>