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”来调整执行顺序。