Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 21 Apr 2020 23:43:24 -0700
From:   Christoph Hellwig <hch@infradead.org>
To:     huobean@gmail.com
Cc:     alim.akhtar@samsung.com, avri.altman@wdc.com,
        asutoshd@codeaurora.org, jejb@linux.ibm.com,
        martin.petersen@oracle.com, stanley.chu@mediatek.com,
        beanhuo@micron.com, bvanassche@acm.org, tomas.winkler@intel.com,
        cang@codeaurora.org, linux-scsi@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/5] UFS Host Performance Booster (HPB v1.0) driver
Message-ID: <20200422064324.GF20318@infradead.org>
References: <20200416203126.1210-1-beanhuo@micron.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200416203126.1210-1-beanhuo@micron.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Apr 16, 2020 at 10:31:21PM +0200, huobean@gmail.com wrote:
> From: Bean Huo <beanhuo@micron.com>
> 
> Hi,
> I disclose my development/changes on UFS HPB (UFS Host Performance Booster) to
> the community, as this would enable more UFS developers to test and start an
> iterative review and update process.
> 
> The HPB is defined in Jedec Standard Universal Flash (UFS) Host Performance
> Booster (HPB) Extension Version 1.0, which is designed to improve  read
> performance by utilizing the host side memory. Based on our testing, the HPB
> can increase the random read performance by up to about 46% in the random read.
> 
> The original HPB driver is from [1]. Based on it, I did optimizations,
> simplifications, fixed reliability issues, implemented HPB host control mode
> and make it much more readable. which's pushed to here [2] as V1.
> 
> 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 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.

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.