PCIe Chapter 36：交易依賴、ID-Based Ordering 與 Message

Table 2-42 的 Yes，為什麼容易讀反？

先固定觀察方向：Column是先發送的交易，Row是後發送的交易，表格問的是後者能否超越前者。接著到pp.223–224讀格子的條件，尤其a／b兩種情況；只看一個No或Yes會漏掉屬性例外。

作者案例：同一要求者、同TC，一般Posted資料寫入之後接Posted通知寫入，沒有適用放寬條件。按A2a，後者不得超越前者。這只說明該排序關係；資料是否已持久保存，或CPU需要何種記憶體屏障，仍要按相應裝置與平台規則處理。

兩筆交易相遇時，怎麼查排序表？

教學假設：以下每列都是獨立情境；兩筆交易使用同一個 Traffic Class（TC，流量類別），並在同一個轉送位置比較。先把較早發出的交易放在 Table 2-42 的欄，再把較晚發出的交易放在列，最後讀表格下方的對應條文。

手機閱讀時，可左右滑動表格查看完整內容。

表中 RO 是 Relaxed Ordering（放寬排序），IDO 是 ID-Based Ordering（依身分放寬排序）。例如第二列看的是後發 Read 的 IDO，再比較兩筆 Requester ID；FLIT Mode 還要連同 Requester Segment 一起比較。不是只要某處 Enable 為 1，就能代替檢查實際 TLP 的屬性。

TLP

Transaction Layer Packet，交易層封包

Table 2-42 適用同一 TC；Flow-Through IDE Stream 有不同排序要求，須另讀 §6.33.4。規格允許超越也不保證一定會發生；應用程式的資料可見性與同步仍需平台及裝置文件共同確認。

IDE

Integrity and Data Encryption，完整性與資料加密

No Snoop 與交易排序有什麼關係？

No Snoop 是交易層封包的快取一致性屬性。先讀 Base 6.0 §2.2.6.5 的 Table 2-13：值為 0 時，預期由硬體維持快取一致性；值為 1 時，則不預期硬體提供這項一致性。這個屬性本身不改變 Transaction 的排序。要判斷兩筆交易能否互相超越，仍須回到本章的 Ordering Rules Table，檢查適用的 Traffic Class、交易種類與其他屬性。

接著讀 Device Control Register 的 Enable No Snoop：控制位為 1，表示 Function 在符合條件時獲准將自己發起的交易設為 No Snoop=1，並不表示每筆交易都會如此設定。即使控制位為 1，Function 也只有在能保證該交易位址不在系統任何快取中時，才可設定此屬性。控制位可以固定為 0，預設值則為 1。控制位的讀值和某一筆封包的實際屬性，要分別確認。

【模擬資料】某 Function 的 Enable No Snoop=1，觀察到一筆 Memory Write 的 No Snoop=0。這兩個值可以同時成立：控制位允許在符合條件時使用 No Snoop，但這筆封包仍選擇預設一致性處理。若改看到 No Snoop=1，還需要平台與軟體的記憶體管理資訊，才能確認該位址是否符合使用條件；不能只憑這個 bit 宣稱應用程式一定讀到最新資料。

Configuration Request、I/O Request、作為 Message Signaled Interrupt（訊息式中斷）的 Memory Request，以及 Message Request（規格特別允許者除外），都必須將 No Snoop 清為 0。這些類型限制要和控制位一起檢查。

PCI Express Base 6.0 §2.2.6.5、Table 2-13，文件頁／PDF 頁 161；§7.5.3.4、Figure 7-25、Table 7-21，文件頁／PDF 頁 959–961。平台快取與軟體同步行為需查相應平台文件。

想開 IDO 提升效能，要先看哪種案例？

先用Figure E-1放回拓樸，再看Appendix E的單一對象與多對象通訊。只與一個對象直接通訊，和同時透過主記憶體及P2P協作，風險不同。E.4.1示範兩個裝置都更新同一記憶體位置時，放寬後可能改變最後結果。

Appendix D則從資源依賴切入，描述收到一種交易卻必須等另一種交易送出時，如何形成等待關係。它沒有替所有平台訂完跨TC依賴規則，系統仍須在配置TC／VC時理解自身限制。

VC

Virtual Channel，虛擬通道

不同 Requester 的交易可以超越，就一定安全嗎？

教學情境，依 Appendix E.4.1：Device Y 先對主記憶體寫入資料，接著以 Peer-to-Peer（P2P，裝置對裝置）寫入通知 Device Z；Z 收到通知後，向同一記憶體位置寫入自己的資料。

依 Figure E-1 先找 Y、Z、Switch 與 Root Complex，再把三筆交易依觀察位置排好。假設 Y 和 Z 寫入使用同一 TC，並在 Root Complex 的共同處理位置比較。前兩筆來自 Y；Z 後來的寫入則有另一個 Requester ID。若 Z 的 Posted Write 設置 IDO，且 Table 2-42 A2b 的其他適用條件成立，Root Complex 可能讓它超越仍在等待的 Y 寫入，最後的記憶體內容便可能改變。

這個案例說明：用 Requester ID 區分交易流，無法單獨描述跨裝置的資料依賴。是否可以啟用 IDO，要先理解哪些裝置和記憶體共同參與，再依各 TLP、路徑與同步方式判斷。附錄提出同步的可能方向，具體協定仍由裝置與平台定義。

TLP

Transaction Layer Packet，交易層封包

Appendix D 處理另一種問題：不同 TC 的封包若在有限緩衝資源之間形成循環等待，可能造成死結。它討論的是資源依賴；不要把不同 TC 缺少一般排序要求，理解成系統永遠不會產生依賴。

要改 Bus Number，先清 Bus Master Enable 就夠嗎？

§6.4把停止流程分成多項責任：阻止裝置新要求、阻止軟體新存取、確認裝置服務中的要求完成、確認已發出的Non-Posted要求完成，以及確認Posted要求已到目的地。Transactions Pending只涵蓋其中一部分。

因此，先與驅動協調停止使用，再按要求種類確認在途工作。更改身分時仍有Request／Completion在途，可能讓原有識別失效；不能把一個控制位已清零當成所有交易都已排空。

準備改 Bus Number 時，要確認哪些工作已停下來？

教學情境：驅動程式準備重新配置一個 Endpoint。先依 §6.4 與驅動協調，阻止裝置產生新 Request，也停止軟體送往裝置的新 Request，並確認裝置正在服務的要求已完成。

接著看 Device Status 的 Transactions Pending：它用於判斷該 Function 已發出的 Non-Posted Request 是否完成；這個欄位本身不代表先前的 Posted Write 都已到達。仍須依交易使用的 TC、排序屬性與裝置同步機制，確認 Posted Request 的目的地已收到相應工作。

§6.4 說明裝置對系統記憶體使用 TC0 的 Write，可由 Host 讀取裝置來完成相應 flush；對其他 TC 需要適用的同步機制。這是特定條件下的路徑，不能忽略 RO、IDO 或平台記憶體規則。若裝置間有 P2P 互動，即使使用 TC0，也需要參與裝置之間明確的同步協定。

想查 Message Code，應先看附錄 F 還是封包圖？

先用Table F-1以用途找到Message Code、路由與Msg／MsgD，再沿它指向的正式章節讀完整格式與規則。例如頁面要求、失效通知與LTR都能從這個入口接回前章。Table F-1也提醒其他規格可能新增Message，版本較新的定義不一定收錄在這份Base 6.0清單。

LTR

Latency Tolerance Reporting，延遲容忍度回報

查到一個代碼後，怎麼找到完整格式？

教學情境：要找 Invalidate Request，先在 Appendix F 的 Table F-1 找到這一列：Message Code 0000 0001b、Routing 010b、類型 MsgD。再沿同一列的參照讀 §10.3.1，才能確認該功能的封包欄位與處理條件。

若要找 Function Readiness Status（FRS，Function 就緒狀態），改查 Table F-2 的 PCI-SIG-Defined VDM Subtype：0000 1001b。它是子類型，不能當成 Table F-1 的一般 Message Code。接著讀 §2.2.8.6.3，並結合 Chapter 34 的就緒事件與佇列流程。

兩張表是 Base 6.0 當時的索引；其他規格後續定義的 Message 或 Subtype 可能尚未列入。索引指出下一個閱讀位置，完整適用條件仍以對應定義為準。

遇到 Vendor_Defined Message，先看哪個欄位？

先從 Table 2-28 辨認 Message Code：7Eh 是 Vendor_Defined Type 0，7Fh 是 Type 1。這個 Type 表示訊息的種類，不是 TLP Header 中判斷有無 Payload 的 Type：兩者都可能使用無資料的 Msg 或帶資料的 MsgD。

接著依目前模式選 Figure 2-47（Non-Flit）或 Figure 2-48（Flit），讀 Vendor ID 與 Routing。共通格式中，Route by ID 使用 bytes 8–9 作 Destination ID；其他路由下這兩個 bytes 為 Reserved。個別訊息可以對同一位置另作定義：例如 Hierarchy ID Message 雖採 Broadcast，仍在此放入 Hierarchy ID。Vendor ID 位於 bytes 10–11；bytes 12–15 供訊息定義使用。若 Vendor ID 是 0001h 且 Message Code 是 7Fh，再到 §2.2.8.6.1 和對應模式的 Figures 2-49／2-50，依 Subtype 找 PCI-SIG Defined VDM 的具體規則。例如 09h 是 FRS，後續事件與對象見 Chapter 34。

FRS

Function Readiness Status，功能就緒狀態

兩種訊息送到不支援它的 Completer 時，處理方式不同：Type 0 依規則偵測並回報 Unsupported Request；Type 1 由 Completer 靜默丟棄。這個差異描述 Completer 的處理，不能只憑中途未看到訊息就推論它已到達。Switch 對 Routing 000b、010b、011b 的收到訊息有轉送要求；100b 則是本地終止。

共通格式的 Attr 並非 Reserved，但個別訊息可以訂出更嚴格的欄位規則；FRS 就將 Attr 設為 Reserved。一般 VDM 的 Requester ID 在 Non-Flit Mode 由實作決定，而 Flit Mode 須使用與 Requester 關聯的值；PCI-SIG Defined VDM 另要求該欄位使用與 Requester 關聯的值。涉及 PCIe-to-PCI/PCI-X Bridge 與 PCI-X Device ID 相容時，還須查該 Bridge 規格的額外限制。

版本與來源

本章以 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB）為準，文件頁與 PDF 頁相同。案例的配置與讀值均為作者假設，並非實機測量。