On Tue, 2023-03-28 at 20:17 -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 3/28/23 03:29, Po-Wen Kao wrote:
> > A dedicated queue for dev commands is not mandatory, hence let
> > UFS_MCQ_NUM_DEV_CMD_QUEUES become module parameter `dev_cmd_queues`
> > to allow sharing first hw queue for dev commands.
>
> Which queue is selected for device management commands?
Queue 0 is selected by default.
@@ -423,8 +441,11 @@ int ufshcd_mcq_init(struct ufs_hba *hba)
/* The very first HW queue serves device commands */
hba->dev_cmd_queue = &hba->uhq[0];
>
> What is the impact of this change? If a device command is queued on a
> queue with multiple pending commands, does that mean that it can take
> long for the device command to reach the UFS device?
>
> The answer to the above questions should be in the patch description.
> Please expand the patch description.
I will make commit message clear in next update.
> > +unsigned int dev_cmd_queues = 1;
> > +module_param_cb(dev_cmd_queues, &dev_cmd_queue_count_ops,
> > &dev_cmd_queues, 0644);
> > +MODULE_PARM_DESC(dev_cmd_queues,
> > + "Number of queues used for dev command. Default
> > value is 1");
>
> I prefer a solution that does not require any new kernel module
> parameters. That means either a dedicated device command queue for
> all
> host controllers or no dedicated device command queue for any host
> controller.
The motivation of this patch is to adapt UFS driver to different host
hardware. IMHO, some host may implement a dedicated (extra) queue for
dev commands but not all does. In general, one hw queue per CPU (IO
queue) topology is desired, hence sharing a hw queue is inevitable on those host without a dedicated dev cmd queue. The host with dedicated queue will keep the benifit of having fast channel for dev commands.
Thanks
