Virtual Channel机制

SpringZZZZZZ

于 2024-08-23 10:34:02 发布

阅读量515

点赞数 10

分类专栏： PCIe 6.2 文章标签：服务器网络运维

本文链接：https://blog.csdn.net/weixin_43770660/article/details/141327462

版权

PCIe 6.2 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

写在前面：

1、本文参考来源PCIe 6.2，2024.02.25

2、仅作为个人学习记录和分享，转载请注明出处

3、个人能力有限，协议的理解均基于个人，如有错误还望指出

一、简介

VC机制是用来支持通过TC来差异化各个traffic的传输的。每个VC具备不同的队列/缓缓存和控制逻辑资源，其VC之间的流量控制（在FM下采用Shared Flow Control来降低对资源的需求）完全独立，这两者是解决流量阻塞的关键点，避免了单一流量对系统的阻塞。通过将不同的TC映射到不同的VC上可以对应实现携带TC的traffic映射到不同的virtual channel上，且可以通过VC ID来指定VC。对不同流量的差异化处理除了取决于TC配置的不同导致TC/VC映射的不同之外，还取决于基于VC-Port-Function的调度机制。其中TC的定义参见TLP-Common Packet Header Fields第一小节NFM的Common Header定义

在FM下，VC0由硬件通过专属FC信用池和共享FC池（对所有VC均有效）来自动的进行初始化，如果软件使能了其他VC，则同样的通过专属FC信用池和共享FC池来对每个VC进行初始化。允许在仅实现单一VC的情况下将专属credit初始化为0（不使用merged credit，使用merged credit的情况下Non-Posted被允许初始化为0）。

VC ID是用来对VC进行唯一标识的。PCIe的端口可以支持1-8个Virtual Channel，每个端口都是独立配置和管理的，所以可以实现对每个端口根据需要实现其能够支持的不同的VC个数。

注意DLLP包含FC统计使用的VC ID信息，但是TLP并不包含。TLP中包含的TC信息，在每个链路上的端口上进行VC映射之后才会包含VC ID信息，所以对TLP来说其FC控制实际上使用的是TC。

将一个VC ID赋值给VC硬件资源需要遵循如下规则：

对每个端口来说，其VC ID分配必须是唯一的，即在同一个port中同一个VC ID不允许被分配给不同的VC硬件资源。
对于同一个链路的两端，其VC ID的分配必须是一致的，包括VC的个数以及其ID
对实现了MFVC Extended Capability结构的MFD（Multi-Function Device）来说，其VC硬件资源跟MFVC拓展能力级实现的VC的硬件资源不同，此外VC ID使用于VC和MFVC拓展能力级实现的VC，但是VC ID分配的一致性并不适用于MFVC拓展能力实现的VC
VC ID 0固定被分配给默认VC

二、TC/VC映射

任一被支持的TC（Traffic Class）都必须被映射到一个VC（Virtual Channel）上。TC0映射到VC0是固定的，其他TC的映射需要满足如下规则：

一个或者多个TC可以被映射到同一个VC上
在任一端口或者EP的Function上，一个TC不允许被映射到多个VC上
TC与VC的映射对同一链路上的两端的端口来说必须保持一致
如果支持UIO的话，则必须支持VC3，且必须使用VC3来传递UIO
如果支持UIO并且其可以使用两个VC的话，第二个VC必须为VC4

表1 TC-VC映射示例

支持的VC配置	TC/VC映射选择
VC0	TC(0-7)/VC0
VC0,VC1	TC(0-6)/VC0,TC7/VC1
VC0-VC3	TC(0-1)/VC0,TC(2-4)/VC1,TC(5-6)/VC2,TC7/VC3
VC0-VC7	TC[0:7]/VC[0:7]

TCn/VCk：TCn映射到VCk上

TC(n-m)/VCk：在n-m范围内的TC均映射到VCk上

TC[n:m]/VC[n:m]：TCn/VCn，TCn+1/VCn+1，...，TCm/VCm

图1 单VC映射示例

图2 多VC映射示例

三、VC调度

调度是VC机制的重要部分，一般来说支持对特定实现的可配置性，通常来说定义调度出于如下几个目的：

为了防止transaction的伪超时和确保数据流的传输
为了在PCIe结构内对不同的数据流提供差异化服务
在组件之间提供确定的(且相当小的)端到端延迟的受保障的带宽

图3 Switch中不同的数据流示例

从图中可以看出来自不同入口的transaction需要在不同的出口上进行发出，其中transaction携带不同或相同的TC，Switch采用不同的方式，包括TC/VC映射表-端口调度-VC调度等方式，将不同流量等级的transaction以符合预期的方式传递到对应的接口上进行发出。一般可以将其分成如下几个步骤：

根据TLP Header的相关信息TLP包在入口端口上被接收
根据端口的TC/VC映射表判断当前TLP(下面采用transaction进行代指)使用端口的哪个VC
根据路由机制将transaction路由到出口端口上
根据端口的TC/VC映射表决定端口的哪个VC接收transaction
根据端口调度逻辑判断接收来自哪个端口的trnsaction
根据VC调度决定使用哪个VC将transaction发出

1.VC调度

一般来说VC调度包含如下三种调度方法：

严格优先级
轮询调度
加权轮询调度

图4 VC ID和优先级示例

严格优先级调度：基于内部优先级，例如VC0最低，VC7最高。如果硬件支持严格优先级的话，允许软件配置上层优先级和下层优先级，上层优先级按照严格优先级进行操作，下层优先级需要在无上层优先级包的情况下进行操作。严格优先级存在高优先级的传输占用过多时间导致低优先级出现传说超时的情况，软件需要合理的分配。

轮询调度：在事务层上，轮询调度对所有的traffic来说，每个traffic具备相同的机会被调度到（注意这里并不表示每个traffic的带宽使用是等价和公平的），适用于处理包含相同优先级的无序流的情况。

加权轮询调度：其在轮询调度的基础上，对对象分配不同的权重，来实现差异化处理。一般来说建议支持加权轮询调度的组件实现可编程的轮询调度机制（programmabled WRR）

2.端口调度

对Switch来说：端口调度指的是来自别的入口端口的被映射到相同VC的traffic在出口端口上的调度

对Root Port来说：端口调度指的是来自别的Root入口端口的被映射到相同VC的peer-to-peer traffic在Root出口端口上的调度

一般遵循如下三种调度方式：

硬件固定的调度，例如轮询调度
Programmable WRR arbitration
Programmable Time-based WRR arbitration

Time-based WRR调度简单理解就是从时间的角度上进行调度，将端口上发送transaction的时间进行切片，在每个切片上对不同的transaction进行调度。

3.MFD和Function调度

此调度就是在上述的调度中增加了不同Function之间的调度。如图4所示。其每个Function都可选择性的包含VC Extended Capability结构，即每个Function都包含TC/VC映射-可选的端口调度-可选的VC调度。对于MFVC Capability结构中的调度一般顺序为TC/VC映射->Function调度->VC调度。

图5 多功能调度模型

图6 多功能调度错误模型示例

图5中各参数含义为：

OK--成功

MF@F0：Malformed TLP，在Function 0上报告

MF@F1：Malformed TLP，在Function 1上报告

MF@F2：Malformed TLP，在Function 2上报告

n/a：不适用

补充：在每个出口端口上都包含VC流量控制逻辑和VC排序控制逻辑

四、实时性支持

1.对软件配置的要求

软件必须为实时性transaction指定一个或者多个TC

软件必须确保以相同Completer为目的的所有实时性请求的Attr域都是固定且相同的

软件必须配置所有VC资源，以支持在必要的带宽和延迟下进行服务(仲裁)，以满足应用程序的目标。这可以通过使用严格优先级、WRR或硬件固定仲裁来实现。

软件不可以在一个给定的VC上混合实时性traffic和非实时性traffic

软件必须观测由Port或者RCRB报告的Maximun Time Slots capability

软件不可以将所有链路流量都分配给实时性traffic

软件需要合理配置MPS/MRRS来实现低延时要求

2.对Requester的要求

读请求中包含的长度不可以超过MPS

在同步traffic的目标为RC且RCRB标识如果不要求所有transaction都置1 No Snoop的Attr位（通过Reject Snoop Transaction位来标识）则无法满足实时性带宽和延迟的要求的情况下，必须在TLP Header中置1 Attr[0]位，否则此transction会被拒绝。

3.对Completer的要求

Completer不允许在正常操作条件下通过FC机制产生压力从而拒绝实时性请求

Completer必须通过VC Resoure Capability寄存器的Maximum Time Slot域来报告其实时性带宽能力

Completer必须观测最大实时性事务延迟

当RC作为Completer时，其必须至少实现一个RCRB且在相关端口上支持Time-based Port调度

五、相关寄存器

对VF来说其采用跟其相关的PF的VC，VF本身并不包含VF Capability。但是MFD的每个Function都具备MFVC Capability

图7 Virtual Channel Extended Capability Register Structure

图8 MFVC Capability Structure

图9 Streamed Virtual Channel Extended Capability Structure

六、规则总结

一些TC/VC机制的规则总结：

所有设备都必须支持通用I/O TC（TC0必须实现默认VC0）
每个VC都具备独立的流量控制
在不同的VC或者TC之间没有排序的依赖关系
Switch上支持peer-to-peer能力对所有VC均适用
MFD在不同功能之间的peer-to-peer能力适用于MFD支持的所有VC。
在接收设备上，如果其在入口上接收到没有被映射到任一使能的VC上的TC的transction，其需要被处理为Malformed TLP
对Switch来说，包含没有被映射到任一使能的VC的TC的transaction（在出口上）需要被处理为Malformed TLP
对RP来说，包含没有被映射到任一使能的VC的TC的transaction（目标为RCRB）需要被处理为Malformed TLP
对MFD来说，包含没有被映射到任一使能的VC的TC的transaction（在MFVC Extended Capability结构中）需要被处理为Malformed TLP
Switch必须对每个PORT都支持独立的TC/VC映射配置
RC必须对每个RCRB（Root Complex Register Block）-相关联的RP-任何RCiEP（Root Complex Integrated Endpoint）都支持独立的TC/VC映射配置
在一个给定的端口上不可以同时使能SVC（Streamed Virtual Channel Extended Capability）和VC/MFVC

SpringZZZZZZ

关注

10
点赞
踩
12

收藏

觉得还不错? 一键收藏
0
评论
Virtual Channel机制

VC机制是用来支持通过TC来差异化各个traffic的传输的。每个VC具备不同的队列/缓缓存和控制逻辑资源，其VC之间的流量控制（在FM下采用Shared Flow Control来降低对资源的需求）完全独立，这两者是解决流量阻塞的关键点，避免了单一流量对系统的阻塞。通过将不同的TC映射到不同的VC上可以对应实现携带TC的traffic映射到不同的virtual channel上，且可以通过VC ID来指定VC。
复制链接

扫一扫