?
續上,隊列管理模塊采用隊列的存儲與控制分離的設計結構,如圖1所示為隊列管理模塊的結構框圖。
?
圖1 隊列管理結構
由于提交隊列管理單元使用表單管理隊列信息,所以使隊列具有了可動態配置的屬性,通過修改表單的信息便可以修改隊列數量和深度。在實際應用中,當出現大量隨機數據讀寫請求時,可以通過修改表單增加隊列數量和深度,增強隨機讀寫性能;在順序讀寫數據時,可以清除表單減少隊列數量和深度,降低資源占用和功耗。
對于完成隊列,設置一個完成隊列管理單元、一個完成條目解析單元和一塊異常完成條目緩存。完成管理單元中同樣包含了完成隊列表單,與提交隊列表單不同的是完成隊列表單中只包含了門鈴地址、隊列深度和門鈴頭、尾指針,并且只設置了一個admin完成隊列和一個I/O完成隊列。
這樣的結構設計基于兩個方面的考量:首先,當完成條目狀態為正常完成時,只需將完成條目中的指令ID釋放到ID池,將對應提交隊列ID的門鈴頭指針更新到提交隊列條目,當完成條目狀態為異常時,將其寫入異常完成條目緩存等待處理,這些過程由完成條目解析單元在短時間內并行處理,不會出現完成隊列寫請求的阻塞,因此不需要設置多個I/O完成隊列和完成條目的存儲空間。其次,由于ID池的存在,所有的NVMe指令都具有一個唯一的ID,完成條目中的提交隊列ID不再作為指令的標識,因此僅使用一個I/O完成隊列對應多個I/O提交隊列是可行的,并且異常的I/O完成條目和異常的admin完成條目存放在同一個緩存中也不會影響ID的辨識作用。
在有新的提交條目寫入提交隊列和新的完成隊列寫請求時,提交隊列管理單元和完成隊列管理單元向對應的隊列發起門鈴寫請求,這些請求經過Round Robin仲裁器的仲裁后被發送給SSD。實際上,隨著仲裁輸入數量的增加,仲裁的效率和時序也會變差[[i]]。假設采用完成隊列和提交隊列一一對應的結構,仲裁的輸入數量將是提交隊列數量的2倍,要保證仲裁效率和良好的時序,只能降低提交隊列數量,導致性能下降。而完成隊列管理單元所實現的結構只占用兩個仲裁請求輸入,基于此可以增加更多的I/O提交隊列,充分發揮SSD性能。
B站已給出相關性能的視頻,如想進一步了解,請搜索B站用戶:專注與守望
鏈接:https://space.bilibili.com/585132944/dynamic?spm_id_from=333.1365.list.card_title.click
?
審核編輯 黃宇
-
nvme
+關注
關注
0文章
256瀏覽量
23282
發布評論請先 登錄
NVMe高速傳輸之擺脫XDMA設計十:隊列管理模塊設計(下)
NVMe高速傳輸之擺脫XDMA設計九:隊列管理模塊設計(上)
NVMe高速傳輸之擺脫XDMA設計之十:NVMe初始化狀態機設計
NVMe IP高速傳輸卻不依賴XDMA設計之六:性能監測單元設計

NVMe IP高速傳輸卻不依賴XDMA設計之五:DMA 控制單元設計

NVMe IP高速傳輸卻不依賴XDMA設計之五:DMA 控制單元設計
NVMe IP高速傳輸卻不依賴XDMA設計之四:系統控制模塊

NVMe IP高速傳輸卻不依賴XDMA設計之三:系統架構

NVMe IP高速傳輸卻不依賴便利的XDMA設計之三:系統架構
NVMe IP高速傳輸卻不依賴XDMA設計之二:PCIe讀寫邏輯

評論