PCIe Chapter 16：Traffic Class、Virtual Channel 與仲裁

TC 與 VC 分別在哪裡決定？

VC

Virtual Channel，虛擬通道

TC（Traffic Class，流量類別）是 TLP 上的標籤，沿途保持相同；VC（Virtual Channel，虛擬通道）則由每一條 Link 的映射決定，用來對應佇列、緩衝與流量控制資源。§2.5.1 特別提醒：TLP 沒有 VC ID 欄位，接收端要依 TC/VC Map 找到該 TLP 所屬的 VC。

TLP

Transaction Layer Packet，交易層封包

先查 §2.2.6.6 的 Table 2-14：TC 是 3-bit 欄位，000b 代表所有 PCIe 裝置都必須支援的預設 TC0；001b–111b 代表 TC1–TC7，用於區分服務類別。實際的 TC 標記與 TC/VC 映射由系統軟體決定；TC 數字本身不保證特定頻寬或延遲。規格在這裡討論 PCIe fabric 內的服務，如何換成其他互連的服務政策則超出本規格的範圍。（Base 6.0 §2.2.6.6、Table 2-14，文件頁／PDF 頁 161。）

先讀 Table 2-43（p.233）。在 VC0、VC1 這一列，右欄示範 TC0–TC6 對應 VC0、TC7 對應 VC1。這是一種配置範例；TC0 必須固定對應 VC0，其他受支援的 TC 則由軟體配置。同一個 TC 在一個 Port 或 Endpoint Function 內，只能映射到一個 VC。

再看 Figure 2-88（p.234）的上半部：Endpoint 到 Switch 的 Link 只有 VC0，TC7 在這一段也走 VC0；Switch 到 Root Complex 的 Link 則把 TC7 對應到 VC1。TC7 的標籤沒有改變，改變的是各段使用的資源。必須一致的是同一條 Link 兩端的 VC ID 與映射，並非整個 Switch 的所有 Ports 都採同一份配置。

規格閱讀：§2.5 Virtual Channel (VC) Mechanism，pp.229–230；§2.5.1 Virtual Channel Identification (VC ID)，p.232；§2.5.2 TC to VC Mapping，Table 2-43 TC to VC Mapping Example，p.233；Figure 2-88 An Example of TC/VC Configurations，p.234。文件頁與 PDF 頁相同。

兩端都支援 VC1，還要怎麼把它設成可用？

先配置兩端的 VC ID 與 TC/VC Map，再分別啟用，最後確認兩端的 VC Negotiation Pending 都已清為零。VC Enable 是控制設定；VC Negotiation Pending 表示該通道的協商是否還在進行。單看其中一端的 Enable=1，還沒有走完這段流程。

完成初始化後，VC0 沒有 credit，VC1 還能走嗎？

【模擬資料】沿用前節已完成初始化的 Non-Flit 配置，以下是假設的傳送時點。從 Endpoint 向 Root Port 傳送時，TC0 的 Memory Write 映射至 VC0；TC7 的 Memory Write 映射至 VC1。VC0 的 Posted Data Credit 不足，VC1 則有足夠的 Header 與 Data Credit，TC7 也符合其他排序與傳送條件。

Non-Flit Mode 各 VC 的 Flow Control credit pool 獨立，所以 VC0 這筆封包受阻，不會直接扣掉 VC1 的可用 credit。這也不是「VC0 的所有封包都停住」：同一 VC 仍分成不同的 Flow Control 類別，要依候選封包實際需要的資源判斷。這裡先看 VC 之間的隔離，credit 消耗與更新接到 Chapter 17 繼續閱讀。

Flit Mode 若使用 Shared FC，資源分成專用與共享部分，不能把上面的完全獨立池模型原樣搬過去。§2.6 說明共享 credit 的使用條件；一個 VC 能參與仲裁，仍要依當時適用的資源模型判斷。

FC

Flow Control，流量控制

規格閱讀：§2.6 Ordering and Receive Buffer Flow Control，p.235；§6.3.3.1 的 Implementation Note: VC Control Logic at the Egress Port，p.709。Flow Control 保護相鄰接收端的緩衝，並不代表要求已到達最終 Completer。

兩個 VC 都能傳送時，誰先使用 Link？

先分清仲裁的對象。若流量經過 Switch，用 Figure 6-8（p.708）從左向右讀：先依地址或其他路由資訊找出 Egress Port，再依該出口的 Map 決定 VC。來自不同 Ingress Ports、但要進入同一個出口 VC 的流量，先由 Port Arbitration 決定服務順序；出口內不同 VCs 再由 VC Arbitration 競爭共同 Link。兩者都不是單看封包上的 TC 數字就能決定。

再接 Figure 6-9（p.709），先讀 VC ID 與 Relative Priority，再看右側的優先群組分界。規格確實定義 VC ID 由小到大的預設相對優先次序；若採 Strict Priority（嚴格優先），較大的 VC ID 先服務。若一組 VCs 採 RR（Round Robin，輪流服務）或 WRR（Weighted Round Robin，按權重輪流服務），則須讀對應的仲裁能力、選擇與表格，不能只按 ID 排出所有實際傳送次序。

前面的模擬配置指定 Low Priority Extended VC Count=0，依 §6.3.3.2，所有 VCs 都採 Strict Priority。因此，在同一傳送端兩個 VC 都有合格封包可送時，VC1 的相對優先權高於 VC0。這不是 TC7 自帶的頻寬保留；TC7 只是剛好映射到本例的 VC1。

優先權也不能讓缺少 credit 的封包直接傳送。反過來，若高優先流量持續占用 Link，較低優先流量可能一直得不到服務。§6.3.3.2.1 要求使用 Strict Priority 時調節高優先流量，並由系統軟體安排足夠的低優先服務，避免交易逾時。需要頻寬與延遲保證時，還要接到下一節的全路徑契約。

規格閱讀：§6.3.3.1 Traffic Flow and Switch Arbitration Model，Figure 6-8 Switch Arbitration Structure，p.708；§6.3.3.2 VC Arbitration - Arbitration Between VCs，Figure 6-9 VC ID and Priority Order - An Example，pp.709–710；§6.3.3.2.1 Strict Priority Arbitration Model、§6.3.3.2.2 Round Robin Arbitration Model，p.710；Table 7-202，p.1185。

週期資料需要保證，還要建立什麼？

Isochronous Contract（等時性服務契約）把要求者、完成端與沿路資源的責任連在一起。讀 Figure A-1（p.1521）時，先選一條完整流向：Device A 與 Root Complex 之間，包含向上的 Read／Write Requests 與返回的 Read Completions；Device B 到 Device C 則是另一條 Peer-to-Peer 流向。兩種模型都要核對自己的路徑與服務能力。

接著看 Figure A-2（p.1522）的兩條時間軸。上方是過度配置，分配給等時性要求的資源使其他流量幾乎沒有服務空間；下方是短時間內注入過多要求而造成壅塞。因此契約同時需要資源保留與流量調節。§A.2 再把期間 T、交易數 N、每筆預算負載 Y 與延遲 L 接在一起；只把 TC7 映射到 VC1，還沒有建立這份契約。

本章先建立查閱入口，沒有宣稱已配置完整等時性服務。多個流程共用相同 VC／TC 時，系統還要核對總需求；一般非等時性服務的 TC／VC 分配政策，也不能當成 Base 6.0 對所有平台規定的固定配置。

規格閱讀：§A.1 Introduction，pp.1521–1522；Figure A-1 An Example Showing Endpoint-to-Root-Complex and Peer-to-Peer Communication Models，p.1521；§A.2 Isochronous Contract and Contract Parameters，pp.1522–1523；Figure A-2 Two Basic Bandwidth Resourcing Problems: Over-Subscription and Congestion，p.1522。

版本與來源

本章依 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB）撰寫，文件印刷頁與 PDF 檢視器頁碼相同。配置、讀值與流程圖為作者建立的教學案例，並非實機量測。主要帶讀單一 Link 的額外 VC 啟用；MFVC、完整仲裁表、Shared FC 與完整等時性配置仍須深入。