Re: [PATCH 1/2] scsi: ufs: Add Multi-Circular Queue support

Bart Van Assche
2022-07-29T18:59:18Z

On 7/29/22 09:43, Asutosh Das (asd) wrote:
> I went through the change and fwiu of your proposal is to use
> host_tagset = 1 if HC doesn't support EXT_IID capability.
> That way tags would be shared across 16 HWQs (4-bit IID encoding the
> queue-ids).
> That would also mean that the hba->nutrs would have to be adjusted such
> that the tags(8-bit) don't exceed 255.
>
> Summarily,
> if EXT_IID is not supported:
> host_tagset = 1, maximum configurable hba->nutrs = 16, maximum
> configurable nr_hw_queues = 16.
> maximum number of outstanding commands to host = 16 x 16 = 256.
>
> if EXT_IID is supported:
> host_tagset = 0, maximum confiugrable hba-nutrs = 255, maximum
> configurable nr_hw_queues = 255.
>
> Please let me know if I'm missing something.

Hi Asutosh,

I recommend to always set host_tagset = 1. The performance overhead of
host_tagset = 1 compared to host_tagset = 0 should be negligible for UFS
devices. This will simplify the UFS host controller driver and will
allow us to limit the total number of outstanding commands to the
maximum number of outstanding commands supported by the UFS device. I
expect that we will need to do this. If more commands are sent to the
controller than what the UFS device can queue, the host controller will
decide in which order commands are fetched and sent to the controller.
We want the host to decide in which order commands are queued and not
the host controller. As an example, adding support for HCTX_TYPE_READ
queues will only work as expected if the number of outstanding commands
is less than or equal to what the UFS device can queue.

For host_tagset = 1, we can combine the 4 EXT_IID bits with the 8 bit
task tag and create a single space of 4096 (2**12) tags. The block layer
sbitmap data structure has been designed to minimize contention even if
a single sbitmap data structure is shared across multiple CPU cores.

Thanks,

Bart.