UFS的Command Queue

众所周知，UFS 的一大优点之一就是支持command queue,这里我把关于UFS command queue的几个问题总结一下，希望对大家有用哦~

1. cmd queue代表UFS的多线程吗？有几个queue就代表UFS内部有几个线程吗？
我认为不是这样的。

UFS的queue只是把device收到的cmds queue起来，至于执行的时候是不是多线程，那是另一个问题。

用一个简单的比喻好了。午餐时，大家在餐厅排队打饭，排的队就是所谓的queue,可以排成一队，也可以并排排上几队.而线程呢，就是打饭阿姨们工作的打饭窗口，有几个打饭窗口就是有几个线程。窗口越多，工作完成的越快咯。

2. UFS的queue depth
从host的角度来说，最关心的应该就是queue depth了，因为host只有实时了解cmd queue还有多少个“位置”，才能发命令发的更有效率。所谓的queue depth管理有两种模式：一种是“shared queue”,另一种是“per-logical unit queues”.

2.1 shared queue

就是说整个device有一个固定的queue depth,假如说是32，就意味着发给所有LU的cmd加起来不能超过32，至于每个LU有多少cmd则没有限制。

需要说明的是，QUERY REQUEST UPIU,NOP OUT UPIU,and TASK MANAGEMENT REQUEST UPIU不会被存储在queue中。

2.2 per-logical unit queues

这个是指，每一个LU有自己的queue depth,即使其中一个LU的cmd queue已经满了，不影响其他的LU正常接受命令。

同样的，QUERY REQUEST UPIU,NOP OUT UPIU,and TASK MANAGEMENT REQUEST UPIU也不会被存储在queue中。

2.3 特殊的LU-RPMB LU queue

RPMB LU是一个另类。对它来说可以有三种模式：一种是和其他的LU share queue,规则和2.1描述的一样；第二种是per-logical unit queues，这时，RPMB的queue depth是且只能是1；还有一种情况就是RPMB有自己的cmd queue depth,然后剩余的LU share queue.

讲完了这几种情况，那么host该怎样判断device采用的是哪种模式，以及cmd queue depth是多少呢？host通过读取几个read only的descriptor value来判断，请看下表。

device descriptor bQueueDepth    unit descriptor bLUQueueDepth(except RPMB LU)    RPMB LU descriptor bLUQueueDepth     描述    queue depth
X（1<=X<=255）    0    0    
share queue

device queue depth=X
X（1<=X<=255）    0    1    PRMB queue depth=1;other lu share queue    PRMB queue depth=1;other lu share queue depth =X
0    大于等于1；小于等于255    1    per-logical unit queues    bLUQueueDepth of each logical unit
0    0    0 or 1    queue depth未知    host需要自己设定算法来计算
3. 如果host发送的CMD count超过了queue depth会怎样？
这时，device会回复一个带有“TASK SET FULL status”的response.

4. CMD queue和CMDs in a queue 有优先级区别吗？
对于device来说，发给不同LU的cmd,可以有相同的优先级，也可以有一个LU拥有高优先级。这个通过设置device descriptor bHighPriorityLUN来决定。

对于同一个LU来说，queue中的CMD优先级是和CMD UPIU中的Flags.CP和Flags.ATTR相关的。

Flags.CP和Flags.ATTR的值可以参考如下：

我们知道，UFS在处理HOST的命令时，read的优先级会高于write的优先级。再结合Flags.ATTR和Flags.CP,总的来说，UFS处理host命令的优先级遵守以下顺序：

any cmd with "head of queue" attr

>read cmd with "simple" attr & Flags.CP=1

> write cmd with "simple" attr & Flags.CP=1

= read cmd with "simple" attr & Flags.cp=0

>write cmd with "simple" attr & Flags.cp =0

至于那些“ordered” attribute 的CMD以及除了读写之外的scsi cmd，在queue中的位置不会改变，而且发挥着barrier的作用。就是说，除了“head of queue” cmd可以翻越“ordered” cmd,其他的CMD即使排在后面的比前面的优先级高，也不能翻越“barrier”来调整执行顺序。
————————————————
版权声明：本文为CSDN博主「comeonbestxiaohe」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/comeonbestxiaohe/article/details/81221254