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

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:

quoted

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.

quoted

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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel