從逐Link映射走到雙端VC啟用，以欄位快照帶讀Count、Map、VC ID、Enable與Pending，再區分Port／VC仲裁、優先群組與等時性契約。
read more
PCIe Chapter 16: Traffic Classes, Virtual Channels, and Arbitration
TC (Traffic Class) labels a packet. VC (Virtual Channel) associates traffic with queues, buffers, and flow-control resources. Follow one Link's map through configuration, dual-end enablement, and initialization before considering arbitration and end-to-end service.
- TC
- Traffic Class
Where do TC and VC take effect?
- VC
- Virtual Channel
TC (Traffic Class) is an invariant TLP label. VC (Virtual Channel) selects queues, buffers, and flow-control resources through each Link's map. Section 2.5.1 explicitly notes that TLPs carry no VC ID field: a Port associates a TLP with a VC through its TC/VC Map.
- TLP
- Transaction Layer Packet
Start with Base 6.0 §2.2.6.6, Table 2-14: the 3-bit TC field encodes default TC0 as 000b, which every PCIe device must support; 001b–111b represents differentiated classes TC1–TC7. System software determines the TC labels and TC/VC maps. A TC number alone does not guarantee bandwidth or latency. These service classes apply within the PCIe fabric; translating the policy onto another interconnect is outside this specification. (Printed/PDF p.161.)
Start with Table 2-43 (p.233). Its VC0, VC1 row gives TC0–TC6/VC0 and TC7/VC1 as an example. TC0 is fixed to VC0; software configures other supported TCs. A TC must not map to multiple VCs within a Port or Endpoint Function.
Then read the upper example in Figure 2-88 (p.234). TC7 uses VC0 on the Endpoint–Switch Link and VC1 on the Switch–Root Complex Link. The TC7 label stays unchanged; its local resources change. VC IDs and maps must match across each Link, while different Switch Ports can have different configurations.
Reading route: §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. Document and PDF pages match.
Both ends support VC1. How does it become usable?
Configure matching VC IDs and TC/VC Maps, enable both ends, then confirm that both VC Negotiation Pending bits are clear. VC Enable is a control. VC Negotiation Pending reports unfinished negotiation. Enable=1 at one end alone does not complete the process.
【模擬資料】Teaching assumptions, not measurements of a particular device or platform. Consider one Link between Root Port 00:01.0 and single-Function Endpoint 01:00.0. Both Data Link Layers remain DL_Active. The Link uses Non-Flit Mode; Flit Mode is not supported. There is no MFVC and no arbitration table in use. At each end, Extended VC Count=1, Low Priority Extended VC Count=0, and All VCs Enabled remains 0.
The Count excludes default VC0, so each end has two VC Resource register sets. Initially, VC0 is usable with TC/VC Map FFh; the additional resource is disabled. The goal is TC0–TC6/VC0 and TC7/VC1. Stop new TC7 transactions in both directions and ensure all associated outstanding transactions have ended before changing the maps.
Locate Control and Status in Figure 7-221
Assume Extended Capability traversal found Virtual Channel Extended Capability ID=0002h, Version=1, at offset 180h in the Root Port and 200h in the Endpoint. Each offset belongs to that Function's Configuration Space, not a global memory address.
Figure 7-221 (p.1183) allocates 0Ch bytes per resource. For the second resource, index 1, the Control offset is 14h + 1 × 0Ch = 20h. Status occupies the upper 16 bits of its 32-bit row, so the 16-bit Status offset is 18h + 1 × 0Ch + 2 = 26h. The row start at 24h is not the Status access location.
| Read target | Root Port 00:01.0 | Endpoint 01:00.0 |
|---|---|---|
| VC Resource Control Register (1), 32-bit | 180h + 20h = 1A0h | 200h + 20h = 220h |
| VC Resource Status Register (1), 16-bit | 180h + 26h = 1A6h | 200h + 26h = 226h |
Assign the maps and VC ID before enabling
In Table 7-207 (pp.1189–1191), each TC/VC Map[7:0] bit selects its corresponding TC. At both ends, remove TC7 from VC0, changing its map from FFh to 7Fh. Assign resource 1 VC ID[26:24]=1 and Map=80h, with VC Enable[31]=0. TC7 remains quiesced while no enabled VC temporarily carries it.
With all other bits assumed zero, resource 1's 32-bit Control snapshot is 01000080h. After both ends are prepared, set VC Enable at each end; the snapshot becomes 81000080h. Software updates fields according to their attributes and preserves RsvdP bits; these values illustrate how the fields compose a readback.
Read both Status registers; do not write Pending
Table 7-208 (pp.1191–1192) defines VC Negotiation Pending as Status bit 1, RO, updated by hardware. Its value is defined only while the Link is DL_Active and that VC Enable=1. A displayed zero while the VC is disabled does not establish completed negotiation.
| Two observations after enabling | Root Port 16-bit Status | Endpoint 16-bit Status | TC7 use |
|---|---|---|---|
| Both enables are 1; initialization is progressing | 0000h: Pending=0 | 0002h: Pending=1 | Keep waiting; both ends are not yet complete |
| Both enables remain 1; a later read | 0000h: Pending=0 | 0000h: Pending=0 | VC1 may be used, subject to normal transmission conditions |
Hardware clears Pending when negotiation finishes on exit from FC_INIT2. Check the same VC at both ends. Acting on the Root Port's zero alone misses the Endpoint's unfinished initialization. This Status is not a W1C event field; software cannot complete negotiation by writing 1.
After all intended VCs have been enabled, software may set All VCs Enabled (Port VC Control bit 4) to aid buffer allocation. Leaving it clear must still allow correct operation of enabled VCs. Once set, changing a VC Enable in this Capability while the Link is up has undefined behavior; it is not an ordinary live-switching mechanism.
Connected sources: §7.9.1 Virtual Channel Extended Capability, pp.1181–1184, Figure 7-221 Virtual Channel Extended Capability Structure, p.1183; Table 7-202 Port VC Capability Register 1, p.1185; Table 7-207 VC Resource Control Register, pp.1189–1191; Figure 7-229/Table 7-208 VC Resource Status Register, pp.1191–1192; Table 7-204 Port VC Control Register, pp.1186–1187. Document and PDF pages match.
After initialization, can VC1 progress while VC0 lacks credit?
【模擬資料】Continue with the initialized Non-Flit configuration; the following is an assumed transmission instant. For Endpoint-to-Root-Port traffic, a TC0 Memory Write uses VC0 and a TC7 Memory Write uses VC1. VC0 lacks Posted Data Credit. VC1 has sufficient Header and Data Credit, and the TC7 packet satisfies other ordering and transmission conditions.
| Candidate | Resources | Eligible for transmission arbitration? |
|---|---|---|
| TC0 Memory Write | Required VC0 Data Credit unavailable | This packet waits |
| TC7 Memory Write | Required VC1 credits available | Eligible; it still needs to win arbitration |
Non-Flit Mode has independent FC credit pools per VC, so blocking this VC0 packet does not consume VC1's credits. It also does not establish that all VC0 traffic is blocked: different FC classes within a VC must be evaluated for each candidate. This chapter isolates the VC-level distinction; continue to Chapter 17 for detailed credit consumption and updates.
- FC
- Flow Control
If Flit Mode uses Shared FC, dedicated and shared resources replace this fully independent-pool model. Apply the section 2.6 resource rules before deciding whether a VC is eligible.
Reading route: §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 protects the adjacent receiver's buffers; it does not establish arrival at the ultimate Completer.
When two VCs are eligible, which uses the Link first?
First identify the arbitration participants. For a Switch, read Figure 6-8 (p.708) from left to right: routing selects the Egress Port, whose map selects the VC. Traffic from different Ingress Ports competing for the same egress VC undergoes Port Arbitration. Different VCs at that egress then compete for the shared Link through VC Arbitration. The TLP's TC number alone determines neither decision.
Continue to Figure 6-9 (p.709): read VC ID and Relative Priority, then the priority-group boundary. The specification defines default relative priority in ascending VC ID order. With Strict Priority, the higher VC ID is serviced first. A group using RR (Round Robin) or WRR (Weighted Round Robin) instead requires its arbitration capabilities, selection, and tables; VC IDs alone do not determine every actual transmission order.
The simulated configuration has Low Priority Extended VC Count=0. Under section 6.3.3.2, all VCs therefore use Strict Priority. When both VCs at one transmitter have eligible traffic, VC1 has higher relative priority than VC0. This is not bandwidth reservation inherent in TC7; TC7 is simply mapped to this example's VC1.
Priority cannot bypass a packet's missing credit. Conversely, sustained high-priority traffic can starve lower-priority traffic. Section 6.3.3.2.1 requires regulation of high-priority traffic with Strict Priority and sufficient service for lower-priority transactions to avoid timeouts. Bandwidth and latency guarantees also need the end-to-end contract introduced next.
Reading route: §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 and §6.3.3.2.2 Round Robin Arbitration Model, p.710; Table 7-202, p.1185.
What establishes service guarantees for periodic data?
An Isochronous Contract connects the requester, completer, and fabric-resource responsibilities. In Figure A-1 (p.1521), first follow one complete flow: Device A exchanges upstream Read/Write Requests and returning Read Completions with the Root Complex; Device B to Device C is a separate peer-to-peer flow. Each model needs its own path and service capabilities checked.
Then compare the two Figure A-2 timelines (p.1522). Oversubscription leaves too little service opportunity for other traffic. A concentrated injection burst causes congestion. The contract therefore requires both resource reservation and traffic regulation. Section A.2 relates period T, transaction count N, budgeted payload Y, and latency L. Merely mapping TC7 to VC1 establishes no such contract.
This is a reading entry point, not a complete isochronous configuration. System software must also check aggregate requirements when flows share a VC/TC. Non-isochronous assignment policies are not a universal Base 6.0 platform configuration.
Reading route: §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.
Edition and sources
Authority: PCI Express Base Specification Revision 6.0 (6.0-1.0-PUB). Printed document and PDF viewer pages match. Configurations, readbacks, and the teaching flowchart are author-created, not hardware measurements. This revision teaches additional-VC enablement on one Link; MFVC, complete arbitration tables, Shared FC, and full isochronous configuration remain for deeper coverage.
Complete source locations and purpose
- §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, p.233; §2.5.3 VC and TC Rules, pp.234–235. Table 2-43 TC to VC Mapping Example, p.233; Figure 2-88 An Example of TC/VC Configurations, p.234: labels, resources, and matching maps.
- §2.6 Ordering and Receive Buffer Flow Control, Figure 2-89 Relationship Between Requester and Ultimate Completer, p.235: per-Link flow control and mode-dependent resources.
- §7.9.1 Virtual Channel Extended Capability, pp.1181–1184; Figure 7-221 Virtual Channel Extended Capability Structure, p.1183; Table 7-201 Virtual Channel Extended Capability Header, p.1184: applicability, ID, Version, and resource offsets.
- §7.9.1.2 Port VC Capability Register 1 (Offset 04h), Table 7-202, p.1185: resource count and priority group; §7.9.1.4 Port VC Control Register (Offset 0Ch), Table 7-204, pp.1186–1187: All VCs Enabled.
- §7.9.1.7 VC Resource Control Register, Figure 7-228, p.1189, Table 7-207, pp.1189–1191: Map, VC ID, Enable; §7.9.1.8 VC Resource Status Register, Figure 7-229, p.1191, Table 7-208, pp.1191–1192: Pending validity and dual-end checks.
- §6.3.2 TC/VC Mapping and Example Usage, pp.703–704: remapping and TC Filtering; §6.3.3 VC Arbitration, p.705; §6.3.3.1 Traffic Flow and Switch Arbitration Model, pp.706–709, Figure 6-8 Switch Arbitration Structure, p.708: two arbitration stages.
- §6.3.3.2 VC Arbitration - Arbitration Between VCs, pp.709–710, Figure 6-9 VC ID and Priority Order - An Example, p.709; §6.3.3.2.1 Strict Priority Arbitration Model and §6.3.3.2.2 Round Robin Arbitration Model, p.710: ordering, groups, regulation, and fairness conditions.
- §A.1 Introduction, pp.1521–1522; §A.2 Isochronous Contract and Contract Parameters, pp.1522–1523; Figure A-1 An Example Showing Endpoint-to-Root-Complex and Peer-to-Peer Communication Models, p.1521; Figure A-2 Two Basic Bandwidth Resourcing Problems: Over-Subscription and Congestion, p.1522: entry into the end-to-end contract.
Comments