我們看看UFS中命令或請(qǐng)求是怎么執(zhí)行的

UFS中流淌的數(shù)據(jù)包叫做UPIU（UFS Protocol Information Unit，UFS協(xié)議信息單元），它是固定格式的數(shù)據(jù)結(jié)構(gòu)，用以傳輸應(yīng)用層發(fā)來的命令或者請(qǐng)求，以及跟它們相關(guān)的數(shù)據(jù)或者狀態(tài)信息。它就是SATA中的FIS，PCIe中的TLP。我們看看UFS中命令或請(qǐng)求是怎么執(zhí)行的。

UFS采用“客戶-服務(wù)器”或者說主從的命令架構(gòu)，UFS主機(jī)（Client，命令發(fā)起者，Initiator，他們都是一個(gè)意思）發(fā)送命令或者請(qǐng)求（Request）給UFS設(shè)備（服務(wù)器，Target），然后UFS設(shè)備執(zhí)行命令并返回命令狀態(tài)（Response）。

一個(gè)命令或者請(qǐng)求的執(zhí)行包含下面幾個(gè)階段：

命令階段：主機(jī)發(fā)起命令或請(qǐng)求給設(shè)備，這是“因”；

數(shù)據(jù)階段：傳輸跟命令相關(guān)的數(shù)據(jù)，比如讀寫命令，都涉及到數(shù)據(jù)的傳輸；有些命令不涉及數(shù)據(jù)的傳輸，所以這個(gè)階段并不是總是存在的，跟具體命令和請(qǐng)求相關(guān)。

狀態(tài)階段：設(shè)備執(zhí)行完命令，必須給主機(jī)返回命令執(zhí)行狀態(tài)信息。這個(gè)是“果”，必不可少的。在PCIe中，有Posted和Non-posted的TLP。對(duì)前者，命令執(zhí)行者無需返回命令執(zhí)行狀態(tài)給命令發(fā)起者，對(duì)后者，命令執(zhí)行者必須返回狀態(tài)給命令發(fā)起者。對(duì)UFS來說，它的命令總是non-posted，即設(shè)備必須返回命令狀態(tài)給主機(jī)。

在命令執(zhí)行過程中，無論是處在哪個(gè)階段，UFS主機(jī)和設(shè)備間都是通過UPIU進(jìn)行信息的交互。

1. UFS主機(jī)通過命令或者請(qǐng)求UPIU發(fā)命令請(qǐng)求給設(shè)備；

2. UFS主機(jī)或者設(shè)備通過UPIU傳輸數(shù)據(jù)；

3. UFS設(shè)備通過UPIU返回命令狀態(tài)信息給主機(jī)。

下面我們看看UFS當(dāng)中都有哪些UPIU。

命令或者請(qǐng)求UPIU

前一章看到，應(yīng)用層包括UFS命令、設(shè)備管理器和任務(wù)管理器三個(gè)模塊，傳輸層根據(jù)不同模塊發(fā)來的命令或者請(qǐng)求，分別產(chǎn)生不同類型的UPIU。

UFS命令模塊發(fā)送簡(jiǎn)化版本的SCSI命令，當(dāng)傳輸層收到命令請(qǐng)求后，它會(huì)生成：COMMAND UPIU，把命令封裝起來。

應(yīng)用層通過任務(wù)管理器來管理任務(wù)隊(duì)列，比如終止（Abort）和查詢命令隊(duì)列中的命令。當(dāng)傳輸層收到來自任務(wù)管理器中的請(qǐng)求后，它會(huì)生成：TASK MANAGEMENT REQUEST UPIU，把請(qǐng)求封裝起來。

UFS通過設(shè)備管理器來管理UFS設(shè)備，比如設(shè)置和查詢UFS設(shè)備的配置（Configuration）。當(dāng)傳輸層收到來自設(shè)備管理器發(fā)來的請(qǐng)求后，它會(huì)生成：QUERY REQUEST UPIU，把請(qǐng)求封裝起來。

數(shù)據(jù)傳輸相關(guān)UPIU

當(dāng)主機(jī)發(fā)送了類似讀命令給設(shè)備之后，設(shè)備需要返回?cái)?shù)據(jù)給主機(jī)，設(shè)備通過DATA IN UPIU向主機(jī)傳輸數(shù)據(jù)。

當(dāng)主機(jī)發(fā)送了類似寫命令給設(shè)備之后，主機(jī)需要往設(shè)備寫數(shù)據(jù)，主機(jī)通過DATA OUT UPIU向設(shè)備傳輸數(shù)據(jù)。

UFS的主機(jī)是個(gè)暖男，它在向設(shè)備寫數(shù)據(jù)的時(shí)候，會(huì)考慮到設(shè)備這個(gè)時(shí)候能不能接收數(shù)據(jù)（因?yàn)樵O(shè)備可能這個(gè)時(shí)候沒有足夠的空間接收主機(jī)數(shù)據(jù)），它在向設(shè)備發(fā)了寫命令之后，不會(huì)立刻把數(shù)據(jù)傳輸給設(shè)備，而是在那里等設(shè)備的通知。當(dāng)設(shè)備準(zhǔn)備好接收數(shù)據(jù)，以及接收多少數(shù)據(jù)，設(shè)備通過READY TO TRANSFER UPIU （RTT）告知主機(jī)。當(dāng)主機(jī)接收到該RTT后，才開始按照RTT的信息傳輸數(shù)據(jù)。至于每次傳輸數(shù)據(jù)的多少，RTT中包含這信息，主機(jī)根據(jù)RTT進(jìn)行傳輸。

所以，主機(jī)只有在收到設(shè)備的RTT，才能發(fā)DATA OUT UPIU！

注意，讀命令無需這種機(jī)制。因?yàn)樵O(shè)備從閃存中獲得數(shù)據(jù)后，是設(shè)備控制數(shù)據(jù)的傳輸。對(duì)主機(jī)來說，它在發(fā)讀命令之前，已經(jīng)準(zhǔn)備好足夠的空間用以接收數(shù)據(jù)，所以不存在主機(jī)沒有空間接收數(shù)據(jù)的情況。

狀態(tài)UPIU

前面看到，主機(jī)有三種請(qǐng)求：SCSI命令，任務(wù)管理器發(fā)出的Task Management Request，以及設(shè)備管理器發(fā)出的Query request。針對(duì)不同的命令或者請(qǐng)求，設(shè)備在執(zhí)行完相應(yīng)的任務(wù)后，分別返回對(duì)應(yīng)的狀態(tài)UPIU給主機(jī)。

其它UPIU

除了以上常規(guī)的UPIU，還有其它一些UPIU作為他用。

設(shè)備上電后，主機(jī)檢測(cè)是否與之連接，會(huì)發(fā)NOP OUT UPIU給設(shè)備。我們平時(shí)想看看跟某個(gè)電腦或者網(wǎng)站能否連接上，會(huì)發(fā)一個(gè)ping命令。NOP OUT UPIU跟ping命令作用類似。

當(dāng)設(shè)備收到NOP OUT UPIU后，會(huì)返回NOP IN UPIU。主機(jī)收到該UPIU后，確認(rèn)與設(shè)備連接，然后可以進(jìn)行后續(xù)操作。

最后一個(gè)UPIU就是REJECT UPIU。當(dāng)設(shè)備收到一個(gè)無效的UPIU時(shí)，它會(huì)發(fā)REJECT UPIU拒絕無效的UPIU。

UPIU匯總

偷個(gè)懶，我就直接把UFS spec這張表貼這里。數(shù)了數(shù)，一共12個(gè)UPIU。經(jīng)過我之前的解釋，讀者現(xiàn)在應(yīng)該清楚每個(gè)UPIU的作用了。

讀寫命令中UPIU交互例子

前面我們都是單個(gè)來看UPIU，現(xiàn)在我們以讀寫命令為例，看看他們是如何組合完成命令處理的。

首先是一個(gè)“主機(jī)往設(shè)備讀取96KB數(shù)據(jù)”的例子。

首先，主機(jī)發(fā)送讀96KB數(shù)據(jù)的命令給設(shè)備，然后設(shè)備執(zhí)行命令，分了三批把數(shù)據(jù)返回給主機(jī)，最后返回命令執(zhí)行狀態(tài)給主機(jī)。

然后是一個(gè)“主機(jī)往設(shè)備寫64KB數(shù)據(jù)”的例子。

主機(jī)發(fā)送寫64KB數(shù)據(jù)的命令給設(shè)備，然后在那里等設(shè)備響應(yīng)。很快，設(shè)備說，你可以傳24KB數(shù)據(jù)下來了，于是主機(jī)寫24KB數(shù)據(jù)給設(shè)備；接著，設(shè)備又來通知說可以繼續(xù)傳32KB數(shù)據(jù)，主機(jī)照做。最后，設(shè)備通知說可以把最后8KB數(shù)據(jù)也傳過來，主機(jī)于是寫最后8KB數(shù)據(jù)。最后，主機(jī)收到設(shè)備命令執(zhí)行完成的響應(yīng)。

我們看到，主機(jī)必須等收到RTT后才能啟動(dòng)數(shù)據(jù)傳輸！