PCI Express Technology 3.0:地址空间与事务路由4.5-4.6小节（完）

4.5 TLP路由基础（TLP Routing Basics）

在前几个小节中所讲述的设置建立BARs和Base/Limit寄存器的目的，是为了确保流量（traffic）可以被正确的路由到它的目的Function，之后目的Function就可以看见这些流量中的事务并声明对这些事务的所有权。在例如PCI的这种共享总线（Share-Bus）结构中，所有的流量对于总线上的每个设备都是可见的。只有当流量的目的地在另一条总线，也就是必须跨越一个Bridge时，才会对请求进行路由。由于PCIe链路是点对点的（point-to-point），那么在设备间发送事务时就需要更多的路由操作了。

图 4‑12多端口的PCIe设备有进行路由的职责

如图 4‑12所展现的这样，一个PCIe拓扑使用独立的、点对点的链路来将各个设备与它们的一个或多个邻设备（neighbors）相连接。当流量到达链路接口的入站端（inbound side，或称为ingress port入口端口），这个端口将会进行错误校验，然后做出如下的三个决定中的一个：

接收这个流量并在自身内部使用它。
将这个流量转发至相应的出站（outbound，或者egress出口）端口。
拒绝这个流量，因为入口端口自身既不是这个流量的预期的目标，也不是一个用来对它进行转发的接口。（注意，还存在其他可能的原因导致流量被拒绝）

4.5.1 接收器检查3种类型的流量（Recievers Check For Three Types of Traffic）

假设一条链路处于完全可工作状态，那么每个设备的接收接口（入口端口ingress port）必须对到达的三种链路流量进行检测和评估：Ordered Sets（命令集）、DLLPs（Data Link Layer Packets数据链路层包）以及TLPs（Transaction Layer Packets事务层包）。Ordered Sets和DLLPs对于链路来说是本地的，因此它们不用被路由到另一条链路。TLP可以并且也有可能需要被从一条链路搬移到另一条链路，这种操作所基于的路由信息存在于数据包的Header中。

4.5.2 路由元件（Routing Elements）

对于像RC和Switch这样具有多个端口的设备来说，它们可以在端口之间转发TLPs，它们有时也被称作Routing Agent（路由媒介）或是Routing Element（路由元件）。它们会接受目标为自身内部资源的TLP，也会将TLP在自身入口端口和出口端口之间进行转发。

有趣的是，Switch需要支持Peer-to-Peer的路由，但是对于RC来说这项功能是可选的。Peer-to-Peer流量通常是一个EP向另一个EP发送数据包。

EP只有一条链路，并且它永远不希望看到一个目的地不是它自己的流量，对于它来说只会简单地接受或者拒绝输入的TLPs，而不会进行转发。

4.5.3 TLP路由的三种方法（Three Methods of TLP Routing）

4.5.3.1 整体说明（General）

TLP可以被基于地址路由（Memory或IO），可以被基于ID路由（Bus—Device—Function），或者还可以被隐式路由（routed implicitly）。具体使用的路由办法要根据TLP类型来决定。表 4‑7总结了TLP类型和路由方法的对应关系。

表 4‑7 PCIe TLP类型对应的路由方法

可以发现，Message是唯一一种支持多种路由方法的TLP类型。PCIe协议中定义的大多数message使用的是隐式路由，然而由厂商定义的message则根据需要也可以使用地址路由或者ID路由。

4.5.3.2 隐式路由和Message的目的（Purpose of Implicit Routing and Message）

在隐式路由中，不使用地址或者ID这种路由信息；相反，这个数据包是根据包头中的一个代码（code）来进行路由的，这个代码指示的目的地是拓扑结构中一个已知的位置，例如RC。这种方法简化了使用隐式路由的message路由。

为什么是Message？（Why Messages？）

Message事务在PCI和PCI-X中并没有被定义，但是在PCIe中被引入。加入Message作为一种数据包类型的主要的原因是，为了继续进行PCIe的设计目标之一，也就是大幅度地减少以前PCI中的边带信号（sideband signals）的使用，例如中断pins、错误pins、电源管理信号等等。因此，大多数的边带信号都被带内（in-band）数据包所替代，这些数据包的形式就是Message TLP。

隐式路由是怎么提供帮助的？（How Implicit Routing Helps？）

要使用带内Message来替代边带信号，就需要一种方法来将这些Message路由到正确的收件方（recipient）那里去，而Message的收件方位于一个由数量众多的点到点链路组成的拓扑结构中。隐式路由利用了这样一个事实：Switch和其他的路由元件是可以理解上行（upstream）和下行（downstream）的概念的，且RC是位于整个拓扑结构的最顶端，而EP则是位于拓扑结构的底部。因此举例来说，一个Message可以使用一个简单的代码来表示它应该被送往RC，或者是要被送往下行的所有设备。上述的这种能力能够有效的减少对定义地址范围或是ID列表的需要，而原本是需要针对不同的Message来定义特定的地址范围或是ID列表才能完成路由。

不同类型的隐式路由的相关内容可以参阅“Implicit Routing”一节。

4.5.4 拆分事务协议（Split Transaction Protocol）

像大多数其他串行传输技术一样，PCIe使用拆分事务协议（Split Transaction Protocol），它允许一个目标设备接收一个或多个请求，然后再使用单独的完成包来对这些请求进行响应。相比于在PCI中使用等待态（wait-state）或是延迟传输（retry）来处理访问目标时出现的延迟，拆分事务协议是一种显著的进步。拆分事务协议不再使用通过试探目标是否处于ready才进行访问的高延迟传输机制，而是使用目标设备自己发起响应的方式，无论何时只要目标设备处于ready，它都能自己发起响应，而这个响应所对应的请求是此前就已经给到目标设备的了。这种方式使得每个事务的完成都至少需要两个单独的TLP——Request（请求包）和Completion（完成包），而我们后面将会讲到，对于一个单独的读请求，可能会有多个完成包返回。图 4‑13展示了一个拆分事务中的Request-Completion的组成，这个例子的场景是软件从EP读取数据。

图 4‑13 PCIe事务中的请求TLP和完成TLP

4.5.5 Posted与Non-Posted

为了减少Request-Completion延迟所带来的开销和损失，MWr（Memory Write）事务是Posted的，这意味着从Requester的角度来说，当这个Posted事务刚从Requester发出去，就认为它已经完成了。如果想帮助理解，可以将术语“Posting（邮寄）”和邮政系统（postal system）联系到一起，因为“邮寄”一个MWr和邮寄一封信十分相似。一旦你将要邮寄的信放入邮局邮箱，你就会相信邮政系统会把它送出去，而不必去等待投递的确认。这种方法比等待整个Request-Completion传输完成要快的多。但是，在所有的邮寄方案中都会存在不确定性，事务是否、何时在最终的接收方被成功完成，这是不确定的。

在PCIe中，尽管所有的Posted MWr会带来不确定性，但是相比于这种方法获得的收益来说，这种不确定性是比较少量且可以接受的。相比之下，对IO和配置空间的写操作几乎都会影响设备的行为，且这种影响还是实时与这两种写操作相关联的。因此，对于这样的写请求来说，非常有必要知道它们是否完成以及什么时候完成。基于这样的原因，IO写和配置写必须要是Non-Posted的，它们总是需要收到一个返回的完成包来报告自身操作的状态。

总结来说，Non-Posted事务需要完成包，Posted事务不需要完成包而且也永远不应该收到一个完成包。表 4‑8列出了哪些PCIe事务是Posted的，哪些是Non-Posted的。

下面对表 4‑8的内容进行复述：

Memory Write：

所有的Memory Write请求都是Posted的。不需要返回完成包（Completion）。

Memory Read和Memory Read Lock：

所有的Memory Read请求都是Non-Posted的。需要由Completer返回一个带有数据的Completion（这个Completion由一个或多个TLP组成），Completer通过Completion来传递Requester所请求的数据以及当前Memory Read事务的状态。若发生了错误，那么返回的用于报告错误状态的Completion将不含有数据。

AtomicOP：

所有的AtomicOP请求都是Non-Posted的。需要由Completer返回一个带有数据的Completion，这个Completion中包含了目标位置的原始值。

IO Read和IO Write：

所有的IO请求都是Non-Posted的。对于IO Write和失败的Read来说，需要返回一个不含有数据的Completion。而对于成功的Read来说，则需要返回一个带有数据的Completion。

Configuration Read和Configuration Write：

所有的Configuration请求都是Non-Posted的。与IO请求类似，对于Configuration Write和失败的Read来说，需要返回一个不含有数据的Completion。而对于成功的Read来说，则需要返回一个带有数据的Completion。

Message：

所有的Message请求都是Posted的。虽然路由方法是取决于Message类型的，但是Message都被认为是posted请求。

简单总结来说，只有Memory Write和Message是 Posted的。

表 4‑8 Posted和Non-Posted事务

4.5.6 Header中定义数据包格式和类型的字段

4.5.6.1 整体说明（General）

如图 4‑14所示，每个TLP都含有一个3个或4个DW（12或16byte）的Header。在TLP Header中含有Format和Type这两个字段，它们用来定义剩余的Header的内容，并决定这个TLP在拓扑结构中传递时所使用的路由方法。

图 4‑14 TLP通用的3DW和4DW Header

4.5.6.2 Header中Format/Type字段的编码含义

下方的表 4‑9中总结了TLP Header中的Format和Type字段的编码含义。

表 4‑9 TLP Header中Format和Type字段编码含义

4.5.7 TLP Header概述

当TLP在入口端口（ingress port）被接收到，首先要在物理层和数据链路层对TLP进行错误检查。如果检查无错，那么再由事务层来检查当前TLP使用的是哪种路由方法。基础的步骤为：

Format和Type字段确定了TLP Header的大小、数据包的格式和类型。
根据TLP所使用的路由方法（与Type相关），设备将确定这个TLP的预期接收者是否就是自己。如果确实就是自己，那么设备将接受（或者说是消耗）这个TLP，否则设备将会把这个TLP转发到相应的出口端口（egress port）——根据该出口的排序和流控规则。
如果设备既不是TLP的预期接收方，且设备也并不位于前往预期接收方的路径上，那么它通常会通过一个状态字段为Unsupported Request（UR）的完成包来拒绝这个TLP。

4.6 路由机制的应用方法（Applying Routing Mechanisms）

一旦配置完了系统地址并且也允许开始执行事务，设备将会检查输入的TLP并使用相应的配置字段域来对数据包进行路由。下面的小节将会对PCIe结构中的TLP路由机制基础特点和功能进行描述。

4.6.1 ID路由（ID Routing）

ID路由是用来指向一个逻辑位置——Bus Num，Device Num，Function Num，或者一般称为BDF，这个逻辑位置一般是拓扑结构中的一个Function。ID路由这种机制对PCI和PCI-X协议中用于配置事务路由的方法是兼容的。在PCIe中，ID路由仍然会被用来路由配置包，同时它还可以用来路由完成包和一些Message。

4.6.1.1 Bus号，Device号，Function号的使用上限

PCIe支持的拓扑结构的上限与PCI和PCI-X一样：

一个系统中可以存在的最大总线数量为256，因为Bus号是8bit位宽的。这个总线数量包括了Switch产生的内部总线。
每条总线上最多可以有32个设备，因为Device号是5bit位宽的。一个老式的PCI总线或是Switch、RC的内部总线的下方可以挂载不止一个设备，然而外部的PCIe链路（external PCIe Links）就必须要是点到点的（point-to-point），也就是说外部PCIe链路下方只能挂载一个设备。下行端口（Switch或RC的下行端口）会强制将外部链路的Device号定为Device 0，因此每个外部EP都总会是Device 0。除非使用了替代路由ID解释（Alternative Routing-ID Interpretation，ARI），若使用了ARI那么这个外部Device将没有Device号，关于ARI的更多内容请参阅“IDO（ID-based Ordering）”一节。
每个设备中最多可以有8个内部Function，因为Function号是3bit位宽的。

4.6.1.2 TLP Header中有关ID路由的关键字段

如果一个收到的TLP中的Type字段表示了这个TLP要使用ID路由，那么TLP Header中的ID字段（Bus，Device，Function）就要用来执行路由检查（routing check）。有两种情况：使用3DW Header来进行ID路由，或者使用4DW Header来进行ID路由（这只可能出现在Message路由中）。图 4‑15展示的是一个用于ID路由的3DW Header，图 4‑16展示的是一个用于ID路由的4DW Header。

图 4‑15 3DW TLP Header中的ID路由字段

图 4‑16 4DW TLP Header中的ID路由字段

4.6.1.3 EP进行一次检查（Endpoint：One Check）

对于ID路由，一个EP只会简单地根据自己的BDF来检查TLP Header中的ID字段。每当Function在自己的链路上接收到一个Type 0配置写时，Function将会从配置写事务的TLP Header的byte8-9中“捕获（Capture）”到自己的Bus号和Device号。Function必须将Bus号和Device号存储下来，而具体是存在什么地方，协议中并没有特别指定。保存下来的Bus和Device号被可以被用作Requester ID，例如当这个EP发起请求后，请求的Completer可以将这个Requester ID放进完成包内来让完成包被顺利路由返回，Requester ID就是这个完成包用来路由的信息。

4.6.1.4 Switches（Bridges）每个端口进行两次检查

图 4‑17一个使用ID路由的入站TLP在进行Switch的路由检查

对于一个使用ID路由的TLP来说，一个Switch端口首先要检查这个TLP的预期目的地是不是端口自身，这种检查是通过将端口自身的BDF与TLP Header中的目标ID进行比较来进行的，如图 4‑17中的（1）所示。与EP一样，每个Switch端口将会从上行端口发现的每次配置写（Type 0）事务中，捕获到自己的Bus号和Device号。如果TLP中的目标ID与Switch端口的ID相同，那么Switch端口就会消耗掉（consume）这个TLP，也就是不再转发到其他地方而是自己使用。如果这两个ID字段并不相同，那么Switch端口将会检查这个TLP的目标位置是否在自己的下方。这个检查的方式是，通过检查次级总线号寄存器（Secondary Bus Number Register）和从属总线号（Subordinate Bus Number Register）来查看TLP的目标总线号是否在Switch端口下方的从属总线范围内（包括范围边界）。如果在范围内，那么就将这个TLP向下转发。图 4‑17中的（2）所表示的就是这项检查。如果数据包到达Switch的上行端口，但是没有与端口的BDF相匹配，且也不在从属总线范围内，那么它就会被作为上行端口的UR（Unsupported Request）来处理。

如果上行端口确定了所接收到的TLP的目的地是其下方的一个设备（也就是这个TLP的目标总线在上行端口的从属总线范围内），那么上行端口就会将TLP向下转发，Switch所有的下行端口都会对这个TLP做跟上面一样的检查。每个下行端口都会检查自己是不是TLP的目的地，如果是，那么这个端口将会消耗掉这个TLP而其他端口将会忽略这个TLP。如果TLP的目的地并不是任何一个下行端口，那么下行端口们都会再去检查TLP的目标设备是否在自己下方的从属总线范围中。如果有一个下行端口检查到了这个TLP的目标设备在自己的下方，那么这个端口就会将TLP转发至自己的次级总线，且其他下行端口将会忽略这个TLP。

在这一节中，很重要的一点是要记住Switch中的每一个端口（Port）都是一个Bridge，因此它们都有自己的配置空间，并且它们的配置空间Header必然是Type 1 Header。尽管在图4-17中只展示了上行端口的Type 1 Header，但是实际上每个端口（每个P2P Bridge）都有自己的Type 1 Header，并且在每个端口收到TLP时都会执行上面所述的两次检查。

4.6.2 地址路由（Address Routing）

使用地址路由的TLP引用的内存（系统内存和内存映射IO）和IO地址映射和PCI/PCI-X中事务引用的是一样的。如果一个Memory请求的目标地址小于4GB（即一个32bit地址），那么这个TLP必须使用3DW Header。而如果它的目标地址大于4GB（即一个64bit地址），那么这个TLP就必须使用4DW Header。IO请求的地址被限制为32bit，并且仅当为了支持传统的旧功能时才能被使能。

4.6.2.1 TLP Header中有关地址路由的关键字段

当TLP Header中的Type字段表示这个TLP使用地址路由时，那么就要用Header中的Address字段来执行路由检查。Address字段可以是32bit也可以是64bit的。

使用32bit地址的TLP

对于IO和32bit的Memory请求，它们所使用的3DW Header如图 4‑18所示。因此，这些TLP的目标内存映射寄存器（Memory-Mapped Registers）会存在于4GB内存边界以内。

使用64bit地址的TLP

对于64bit的Memory请求，它们所使用的4DW Header如图 4‑19所示。因此，这些TLP的目标内存映射寄存器（Memory-Mapped Registers）会存在于4GB内存边界之上。

图 4‑18 3DW TLP Header中的地址路由相关字段

图 4‑19 4DW TLP Header中的地址路由相关字段

4.6.2.2 EP对地址的检查

如果一个EP收到了一个地址路由的TLP，那么EP将会用其自身配置Header中的每一个BAR（Base Address Register基地址寄存器）与TLP Header中的Address字段进行比对，如图 4‑20所示。由于EP只有一个链路接口，因此它只会接受或者拒绝数据包，而不会对其进行转发。如果TLP Header中的Address字段与EP的某一个BAR所指示的地址范围相匹配，那么EP就会接受这个TLP。更多的关于BARs是怎么样被使用的内容请参阅“基地址寄存器BARs（Base Address Registers）”一节（原书126页）。

图 4‑20 EP对输入TLP的地址进行检查

4.6.2.3 Switch进行路由（Switch Routing）

对于Switch端口来说，如果一个输入的TLP使用的是地址路由，那么端口会首先检查这个TLP的目标地址是否就是端口本身，这种检查是通过将Switch端口自身Type 1 Header中的两个BAR与TLP Header中的Address进行比对来实现的，如图 4‑21中的步骤1所示。如果TLP Header中的Address字段与某个BAR的地址范围相匹配，那么就说明这个Switch端口就是TLP的目的，端口将会消耗掉这个TLP。如果并未匹配任何一个BAR的地址范围，那么Switch端口将会检查Base/Limit寄存器对，以此来确定这个TLP的目标Function是否在本端口之下。如果Request的目标是IO空间，那么端口将会检查IO Base寄存器和IO Limit寄存器，如图 4‑21中步骤2a所示。而如果Request的目标是Memory空间，那么端口将会检查不可预取Base/Limit寄存器和可预取Base/Limit寄存器，如图 4‑21中步骤2b所示。更多关于Base/Limit寄存器对是如何被评估的信息，请参阅“Base寄存器和Limit寄存器（Base and Limit Registers）”一节。

图 4‑21 Switch检查使用地址路由的入站TLP的路由信息

为了能理解Switch中基于地址的TLP路由，最好要记住一点，每个Switch端口自身都是一个Bridge。下面的步骤描述的是一个Bridge（也就是Switch端口）接收一个基于地址路由的TLP：

TLP向下行移动（由Switch主接口接收并向下转发）

如果TLP的目标地址与Switch端口的其中一个BAR地址范围相匹配，那么这个Bridge（Switch端口）就会消耗掉这个TLP，因为其自身就是这个TLP的目的地。
如果TLP的目标地址落在端口的Base/Limit寄存器所表示的范围内，那么这个TLP就会被转发到次级接口（Secondary Interface），也就是向下转发。
若以上两个条件都不符，且主接口（Primary Interface）上没有其他的Bridge声明拥有这个TLP，那么这个TLP将被Switch主接口当做UR（Unsupported Request）来处理。

TLP向上行移动（由次级接口接收并向上转发）

如果TLP的目标地址与当前Switch次级接口（Secondary Interface）的其中一个BAR地址范围相匹配，那么这个Bridge（Switch端口）就会消耗掉这个TLP，因为其自身就是这个TLP的目的地。
如果TLP的目标地址落在端口的Base/Limit寄存器所表示的范围内，那么这个TLP将被Switch次级接口当做UR（Unsupported Request）来处理（除非这个端口是Switch的上行端口，在这种情况下，这个数据包可能是一个Peer-to-Peer的事务，它将会被转发至下行的另一个端口上，而不是之前接收这个TLP的端口）。
若以上两个条件都不符，那么这个TLP将会被转发至主接口（上行端口），因为这个TLP目的地既不是当前的端口Bridge，也不是这个Bridge之下的任何一个Function。

4.6.2.4 多播能力（Multicast Capabilities）

在PCIe 2.1版本中，新加入了通过指定一个地址范围来进行多播的能力。任何接收到的TLP，只要其地址落在被指定为多播范围的地址范围之内，它的路由或者接受（routed/accepted）就要根据多播规则来处理。虽然这个多播的地址范围不一定会被保留在一个Function的BARs中，也不一定会存在于Bridge的Base/Limit寄存器对中，但是它也需要通过合适的方式被接受或转发。更多的关于多播功能的信息请参阅“Multicast Capability Register”一节。

4.6.3 隐式路由（Implicit Routing）

隐式路由通常被一些Message数据包所使用，它是基于路由元件的感知能力，即路由元件知道拓扑结构具有上行和下行方向，并且拓扑的最顶部是RC。这使得一些简单的路由方法可以不需要去分配目标地址或是ID就能进行路由。由于RC一般都集成了电源管理（power management）、中断（interrupt）和错误处理逻辑（error handling logic），这使得RC基本上是大多数PCIe Message的发送者或者接收者。

4.6.3.1 仅为Message所使用（Only for Messages）

有些Messages使用地址或者ID路由，而不是隐式路由，那么对于这些Message来说，它们的路由机制就跟前面几节描述的ID路由和地址路由相同。然而，对于绝大多数Message来说，使用的路由机制是隐式路由。隐式路由的目的是为了模仿边带信号（side-band signal）的行为，之所以要这样是因为PCIe的设计目标之一就是要尽可能的把原本PCI中的边带信号都清除干净。PCI中的这些边带信号一般是用于Host将一个事件通知给所有的设备，或者是设备将一个事件通知给Host。在PCIe中，我们使用Message TLPs来传输这些事件，而不是通过边带信号。在PCIe中被定义了Message的事件类型有：

电源管理（Power Management）
INTx传统中断信号（INTx legacy interrupt signaling）
错误信号（Error signaling）
锁定事务的支持（Locked Transaction support）
热插拔信号（Hot Plug signaling）
厂商特定信号（Vendor-specific signaling）
插入卡插槽功耗限制设置（Slot Power Limit settings）

4.6.3.2 TLP Header中有关隐式路由的关键字段

对于隐式路由来说，使用TLP Header中的子字段（sub-field）来确定Message的目的地。图 4‑22展示了一个使用隐式路由的Message TLP Header。

图 4‑22 4DW Message TLP Header中的隐式路由相关的字段

4.6.3.3 Message的Type字段总结

表 4‑10展示了一个Message的TLP Header中Type字段的含义。如表中所示，最高的2bit用于指示这个数据包是一个Message，剩下的低3bit用于指示这个Message使用的路由方法。需要注意，Message TLP不管使用哪种路由操作，都只会使用4DW Header。若使用地址路由，那么就用byte8-15来组成64bit地址；若使用ID路由，那么就用byte8和9来组成目标BDF。

表 4‑10 Message请求Header中Type字段的用法

4.6.3.4 EP的处理

对于隐式路由，EP会简单的检查路由子字段（sub-field）是否适合它。例如，EP会接受一个广播Message或是一个终止于EP接收端的Message，但是不会接受隐式目的地为RC的Message。

4.6.3.5 Switch的处理

像Switch这样的路由元件（Routing Element）需要考虑TLP到达了哪个端口，以及TLP的路由子字段是否对这个端口来说是合适的。举例来说：

一个Switch的上行端口可以合法的接收一个广播Message。上行端口将会把这个广播Message复制一份，并向它的所有下行端口都转发。如果一个Switch的下行端口接收了一个隐式路由的广播Message（这意味着这个Message将会向上行移动），这是一种错误，它将被当做畸形TLP（Malformed TLP）来处理。
一个Switch的下行端口可以接收隐式路由目的地为RC的Message，下行端口将会把这个Message转发给上行端口，因为路由元件知道RC永远在上行。而Switch的上行端口并不会从外界接受一个隐式路由目的地为RC的Message，因为这意味着它会向下转发，但是RC却在拓扑结构的上方。
如果隐式路由Message表示它会终止在其接收者的位置，那么接收它的Switch端口将会消耗掉这个Message，而不是将其转发。
对于使用地址路由或者ID路由的Message来说，Switch会按照一般对地址或ID的检查方式来决定是接收它们还是转发它们。

4.7 DLLP和Ordered Set不会被路由

DLLP和Ordered Set的流量并不会被从Switch或者RC的入口端口路由到出口端口。这些数据包只会通过物理层到物理层的链路进行传输，从一个端口移动到另一个端口。

DLLP起源于PCIe端口的数据链路层，先经过物理层，接着离开端口并在链路上传输，然后到达对端端口。在对端端口上，DLLP先经过物理层，然后最终到达数据链路层，DLLP在这里被处理和消耗。DLLP不会继续沿着端口向上到达事务层，因此它并不存在路由。

相似的，Ordered-Set数据包起源于物理层，然后离开端口并通过链路传输，最终到达对端端口。在对端端口上，Ordered-Set在物理层就被处理和消耗。由于Ordered-Set也不会继续沿着端口向上到达数据链路层或者事务层，因此它也不存在路由。

正如本章所讨论的那样，只有TLP会被Switch和RC进行路由，它们起源于源端口的事务层，结束于目的端口的事务层。

原文： Mindshare
译者： Michael ZZY
校对： Karl DGR

欢迎参与《Mindshare PCI Express Technology 3.0 一书的中文翻译计划》
https://gitee.com/ljgibbs/chinese-translation-of-pci-express-technology

转载自：知乎
作者：LogicJitterGibbs

推荐阅读

更多招聘及面经请关注FPGA的逻辑。