[PATCH 2/4] nvme-pci: update sqsize when adjusting the queue depth

Sagi Grimberg sagi at grimberg.me
Sun Dec 25 03:19:43 PST 2022


> Update the core sqsize field in addition to the PCIe-specific
> q_depth field as the core tagset allocation helpers rely on it.
> 
> Fixes: 0da7feaa5913 ("nvme-pci: use the tagset alloc/free helpers")
> Signed-off-by: Christoph Hellwig <hch at lst.de>
> ---
>   drivers/nvme/host/pci.c | 9 +++++----
>   1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 804b6a6cb43a9c..b13baccedb4a95 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -2333,10 +2333,12 @@ static int nvme_setup_io_queues(struct nvme_dev *dev)
>   	if (dev->cmb_use_sqes) {
>   		result = nvme_cmb_qdepth(dev, nr_io_queues,
>   				sizeof(struct nvme_command));
> -		if (result > 0)
> +		if (result > 0) {
>   			dev->q_depth = result;
> -		else
> +			dev->ctrl.sqsize = result - 1;
> +		} else {
>   			dev->cmb_use_sqes = false;
> +		}
>   	}
>   
>   	do {
> @@ -2537,7 +2539,6 @@ static int nvme_pci_enable(struct nvme_dev *dev)
>   
>   	dev->q_depth = min_t(u32, NVME_CAP_MQES(dev->ctrl.cap) + 1,
>   				io_queue_depth);
> -	dev->ctrl.sqsize = dev->q_depth - 1; /* 0's based queue depth */
>   	dev->db_stride = 1 << NVME_CAP_STRIDE(dev->ctrl.cap);
>   	dev->dbs = dev->bar + 4096;
>   
> @@ -2578,7 +2579,7 @@ static int nvme_pci_enable(struct nvme_dev *dev)
>   		dev_warn(dev->ctrl.device, "IO queue depth clamped to %d\n",
>   			 dev->q_depth);
>   	}
> -
> +	dev->ctrl.sqsize = dev->q_depth - 1; /* 0's based queue depth */
>   
>   	nvme_map_cmb(dev);
>   

OK, I think I understand now.

But if you want to patches 1+2 to be taken before 3+4, I'd make sqsize
to be a 0's based value of q_depth after we subtract one entry for queue
wraparound. So others would not get affected from patches 1+2. Then in
one batch make all assignments to sqsize 1's based like in patch 3 and
change nvme_alloc_io_tagset at the same time.

Not super critical, but there is a small chance that if 1+2 are taken
before 3+4, someone may complain...



More information about the Linux-nvme mailing list