[PATCH v2 1/3] scsi: ufs: core: Introduce mcq ops to config cqid

[Powen Kao (高伯文)]

On Wed, 2023-05-31 at 05:48 -0700, Bart Van Assche wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 5/30/23 18:54, Stanley Chu wrote:
> > In addition, some benchmark data shows that the performance can be
> > improved by using fewer CQs to aggregate the interrupt handling of
> > completion requests.
> 
> What has been measured? IOPS only or both IOPS and latency?
> 
> How big is the difference? A few percent or more?
> For which number of SQs and which number of CQs has performance data 
> been measured?
> 
Comparing 8-8 to 8-1 mapping, it shows few percents improvement.

> 
> Would the following work instead of introducing a new vop?
> - Introduce a new capability flag, e.g. UFSHCD_CAP_SINGLE_CQ.
> - Set that flag from inside ufs_mtk_init().
> - Modify the UFS core driver such that the number of completion
> queues
>    depends on the UFSHCD_CAP_SINGLE_CQ flag.
> 
According to spec, driver is free to assign any SQ to CQ mapping. I am
not sure if it's ideal to constrain mapping to specific kind.

> > Therefore, we would like to introduce a vop to allow the host to
> > configure it accordingly.
> 
> We do not accept new vops upstream without a user. Where is the 
> implementation of the new .config_cqid() callback?
> 

Yes, please refer to
"[PATCH v2 3/3] scsi: ufs: ufs-mediatek: Add MCQ support for MTK
platform"

+static int ufs_mtk_config_cqid(struct ufs_hba *hba)
+{
+       struct ufs_hw_queue *hwq;
+       int i;
+
+       for (i = 0; i < hba->nr_hw_queues; i++) {
+               hwq = &hba->uhq[i];
+               hwq->cqid = 3;
+       }
+
+       return 0;
+}


Po-Wen