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

[Bart Van Assche]

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.