为了支持更加灵活的用户逻辑定制，以及基于集中缓存的交换输出调度，解决目前TSN交换开发过程中遇到的用户逻辑定制复杂等问题，经讨论和征求现有用户意见，FAST流水线模型由3.0版本升级到3.1版本。 一、3.0版本存在的问题
      FAST3.0流水线模型如图1所示。其主要特点是增加了Pre-Ingress流水线段，避免GPP（通用分组解析）将IEEE1588v2的PTP协议帧定向到软件处理或丢弃，同时将GOE（通用输出引擎）直接与UDO（用户定义输出）连接，取消了UDO到GOE的反压流控信号，避免了分组输出延时的不确定性，为基于FAST架构的TSN交换实现奠定了基础。      然而，FAST用户在TSN交换功能开发时也面临了两个问题。一是基于FIFO结构的PBuf（分组缓存）只支持先来先服务的输出调度算法，限制了其他输出调度算法的应用；二是Pbuf的写入和读出逻辑分别与GPP和GAC（通用转发动作）模块绑定，强制用户必须同时使用PBuf缓存管理和GPP/GAC的功能，限制了用户自定义逻辑的灵活性。 二、3.1版本简介      FAST流水线3.1版本模型如图2所示，对比3.0版本主要有三个主要变化。   （1）基于BID的Pbuf管理      Pbuf按照RAM的方式组织，内部存储被划分为多个分组缓冲区，每个缓冲区使用体格BID（缓冲区ID）表示。每个到达流水线的分组都会被分配一个BID，BID嵌入分组的元数据在流水线中传递。当流水线需要从Pbuf读出分组时，根据分组的BID向Pbuf发出读出请求。由于BID机制可以支持非FIFO的分组读出顺序，因此可以支持流水线采用更加复杂的分组输出调度策略。   （2）Pbuf管理与GPP和GAC解耦       FAST流水线3.0版本及以前均将Pbuf和写入和读出逻辑分别嵌入GPP和GAC模块，因此使用Pbuf时默认需要流水线配置GPP和GAC模块，这给用户逻辑定制带来不便。例如很多用户交换场景（例如二层TSN交换）并不需要对IP的解析，而GPP包含了IPv4/IPv6以及传输层协议的解析，默认使用GPP使得用户的逻辑难以简化。       在FAST流水线3.1版本中，Ingress流水线的第一个模块固定为IBM（Ingress缓存管理），IBM从CBM（集中缓存管理）获取一个空闲的BID，将分组写入该BID，并将BID嵌入分组元数据中。在Egress流水线中嵌入EBM（Egress缓存管理）模块，负责根据从上游接收到的分组元数据中德BID从CBM中读取分组，向下游模块发出。       CBM负责Pbuf中空闲缓冲区BID的维护，IBM每接收一个分组就分配一个BID，EBM没读取一个分组就回收一个BID。       由于流水线元数据中需要携带BID信息，因此需要将原有FAST架构中的元数据定义进行修改，主要是取消元数据中的SeqNum序列号字段和缩短分组长度字段，详细见《FAST元数据格式规范》。   （3）模块的颜色标注       为了进一步区分模块的属性，支持用户利用现有成熟模块进行快速原型实现以及完全定制自己的模块，FAST模块引入颜色标注机制。 FAST社区会严格测试保证绿色和黄色模块的质量，并提供文档和技术支持。白色模块质量有开发用户负责。经用户授权和FAST社区测试，白色模块也会变成黄色模块。 附：FAST流水线版本历史