Neptune: A Framework for Generic Network Processor Microarchitecture Modeling and Performance Simulation
-
摘要:
网络包处理是网络设备的基本功能，涉及报文修改、校验和与哈希计算、数据包镜像或过滤、统计限速等多项任务. 作为网络包处理的重要部件，网络处理器（network processor，NP）基于处理器结构，为网络设备提供线速的性能和充分的可编程能力，但其架构多样，可分为单段式架构和多段式架构，现有模拟方法无法同时对二者性能进行模拟仿真. 因此，提出一种通用网络处理器的结构模拟和性能仿真框架Neptune，采用多段式架构作为硬件抽象，使用事件链表、核间队列结构为数据通路和多段式架构模拟提供保障，同时满足单段式架构模拟需求. 另外，借助同步图计算模式进行准确的并行模拟，并采用混合事件与时间驱动方法保障模拟高效性. 实际测试中，Neptune以95%以上准确率支持2种架构的模拟，并以3.31MIPS的性能对网络处理器进行模拟，相较PFPSim取得1个数量级的性能提升. 最后，展示了3个运用该框架进行网络处理器优化分析的应用案例.
Abstract:Network packet processing is a fundamental function of network devices, involving tasks such as packet modification, checksum and Hash computation, mirroring, filtering, and packet metering. As a domain-specific processor, network processor (NP) can provide line-rate performance and programmability for network packet processing. However, due to different design requirement, architecture of NP differs, including single-phase NP and multi-phase NP, posing challenges for NP designers. Existing simulation methods mainly target single NP or single architecture and are not available to explore both of the architectures. We propose Neptune, an analyzing framework for generic network processor microarchitecture modeling and performance simulation. Based on detailed analysis, Neptune adopts multi-phase NP architecture as the hardware model while providing ability to simulate single-phase architecture. Besides, Neptune employs event list mechanism and inter-core queues to support simulation of different data paths and various scheduling strategies in multi-phase NP. Furthermore, Neptune utilizes bulk synchronous parallel graph computing mechanism and takes advantage of both event-driven and time-driven simulation, ensuring accuracy and efficiency. Our experiment shows that Neptune achieves over 95% accuracy in simulating both of the architectures and simulates network processors at a performance of 3.31 MIPS, achieving an order of magnitude improvement over PFPSim. We illustrate the universality and capability of the Neptune simulation framework through three specific cases. Firstly, we evaluate multi-phase and single-phase NP, showing that single-phase NP can achieve up to a 1.167 times performance improvement. Secondly, we optimize the packet parsing module using a programmable pipeline and analyze its performance differences. Finally, we use Neptune to test the performance of the network packet processing engine under different thread counts, providing insights for software and hardware multi-threading optimization.
-
随着人工智能（AI）技术的快速发展，大语言模型（large language model，LLM）[1]、多模态大模型[2]等先进AI模型不断涌现，工业界和学术界对AI计算的算力需求也在持续攀升. 具体而言，一方面，当前AI的训练与推理不仅对算力设备的数量提出了更高要求[3]，同时对算力性能的特性也有不同需求[4]. 因此，基于异构计算的计算系统已成为当今业界构建智算集群的主要方式. 另一方面，内存限制成为了制约AI计算的重要问题[5]. 对于训练过程，现有计算架构已无法支撑该过程中产生的激活、优化器状态等内存数据，因此才产生了如Zero[6]、重计算[7]、数据并行训练[8]等折中的内存瓶颈缓解技术. 对于推理过程，KVcache[9]、MoE[10]等技术也对现有内存容量带来了巨大挑战. 缓存一致性技术被认为有望解决计算卡内存受限的问题[11]，诸如英伟达等厂商均提出了高效的缓存一致性互连技术[12-13]，形成紧耦合的融合计算系统[14]，以提升算力资源在并行AI计算中的协同执行效率. CXL协议[15]的提出也论证了一致性互连技术对内存池化、管理、调度等方面的优势. 因此，在未来，结合异构计算与缓存一致性互连技术的异构一致性融合计算系统，将成为AI算力基础设施的重要发展方向.
异构一致性融合计算系统结合类型多样的异构算力，如CPU、GPU、FPGA等，不仅能够充分发挥不同计算架构的优势，还能够通过高效的内存管理和缓存一致性协议协调不同异构算力之间的数据访问与处理. 然而，由于异构计算和一致性互连等关键技术尚未完全成熟，异构一致性融合计算系统的性能预测与评估仍然是当前亟待解决的问题. 例如，如何在建设异构一致性融合计算系统之前以低成本快速地估算其性能，如何评测LLM训练任务在该系统中的执行效率，以及如何发现并优化计算系统中的性能瓶颈，都是异构一致性融合计算系统研究中待解决的核心挑战.
但是，在实际应用中，该计算系统的性能涉及算力的分布、算力与内存的互连架构、任务负载的部署方式、互连拓扑的时延带宽参数等多个复杂变量和指标，因此在实际硬件系统中进行测评的难度和成本往往较高，难以实现. 为此，使用建模与仿真方法对异构一致性融合计算系统进行性能评估，成为一种较为理想的解决方案.
然而，现有的建模与仿真研究大多集中于同构计算系统和非一致性计算系统，难以有效地对异构计算、一致性互连等关键技术进行建模. 目前，建模异构一致性融合计算系统时，主要面临2个挑战：
1）异构一致性融合计算系统的拓扑架构建模具有较大难度. 模型中不仅需要构建异构算力、内存设备等各类器部件之间的互连拓扑，还需考虑异构算力之间的计算性能差异. 以往的建模与仿真工作往往难以同时满足这些需求.
2）引入缓存一致性协议后，计算负载的执行方式会与传统的非一致性系统有所不同. 尽管一致性系统解决了算力主存空间的限制，但算力对远程内存的直接访问开销成为需要特别考虑的因素[16]，这也使得以往的工作难以进行合理建模.
为了解决以上问题，本文研究提出了一种面向异构一致性融合计算系统的性能建模工具HCSim （heterogeneous coherent simulator）. HCSim集成了成熟的分布式系统仿真器SimGrid[17-18]，充分利用其互连拓扑描述能力以及SimGrid-S4U[19]的高效网络仿真能力，从而有效解决了异构一致性融合计算系统的拓扑架构建模难题. 此外，HCSim针对一致性系统的工作特性，设计了结合内存访问特性的负载建模与负载运行模拟方法，使用户能够模拟一致性系统下的工作负载执行方式，并生成可观测的执行轨迹. 进一步地，基于所设计的HCSim，本文研究对异构一致性融合计算系统与LLM训练任务进行了建模，探究了多种变量参数对该系统性能的影响，并提出优化方案以缓解该系统中的通信瓶颈，提高计算系统的整体性能. 本文的贡献有3点：
1）提出了面向异构一致性融合计算系统的性能建模工具HCSim，解决了拓扑架构建模困难以及一致性计算系统负载执行方式存在差异的问题，为异构一致性融合计算系统的性能建模、评估和优化提供了高效的仿真分析工具.
2）基于HCSim构建了在异构一致性融合计算系统下执行LLM训练负载的仿真，并探究了异构算力分布、并行计算规模、时延、带宽等参数对计算系统性能的影响.
3）面向异构一致性融合计算系统中的通信性能优化问题，提出了一致性下的ring-allreduce参数同步方法，并使用HCSim验证了该优化方式对计算系统性能的提升.
本文研究旨在面向新型异构一致性融合计算系统，提出高效、可用的建模仿真分析工具，为工业界和学术界提供低成本的新型计算系统性能与优化方案的评估手段，从而助力新一代AI基础设施与AI应用的创新与发展.
1. 相关工作
1.1 高精度的计算、内存、网络仿真器
计算系统通常涉及处理器计算、内存访存和网络通信等过程[20]，以往已有许多成熟的研究能够对上述3种过程进行高精度的建模与仿真. 对于计算过程的建模与仿真，经典的体系结构仿真器包括高度可配置的开源微架构仿真器Gem5[21]，兼具指令级和全系统仿真的操作系统开发与嵌入式系统仿真器QEMU[22]，以及专门用于GPGPU计算和并行程序性能分析与优化的GPGPU-Sim[23]等；对于内存访存过程的建模与仿真，较为成熟的仿真器包括专注于DRAM访问时序和性能分析的DRAMSim3[24]，以及支持较新内存标准（如DDR4、HBM）的仿真器Ramulator[25]等；在网络仿真器方面，较为广泛使用的是离散事件网络仿真器NS-3[26]，还有支持无线网络、物联网、车联网和数据中心网络的模块化仿真器OMNeT++[27]等.
然而，以上仿真器通常面临计算复杂度高和仿真耗时较大的问题. 例如，使用GPGPU-Sim仿真单个GPU计算任务可能需要长达几天的时间[28]，而NS-3仿真64个节点执行1MB的all-reduce操作可能需要20 min以上[29]. 因此，直接使用这些成熟的高精度仿真器，往往难以在有效时间内对规模较大的计算系统进行仿真与分析，无法满足建模异构一致性融合计算系统的需求.
1.2 面向分布式AI计算系统的性能建模
随着分布式AI计算技术的飞速发展，业界和学界涌现了一系列面向分布式AI计算系统与AI计算任务的性能建模仿真研究，表1中展示了近几年提出的相关工作.
表 1 面向分布式AI计算系统的性能建模工作Table 1. Performance Modeling Work for Distributed AI Computing Systems工作名称 工作简介 AMPeD[30] 针对Transformer神经网络架构的分布式训练任务进行数学建模的研究. Calculon[31] 针对LLM的分布式训练过程进行数学建模的工作. Paleo[32] 早期使用数学模型与有向无环图（DAG）模型建模数据并行、模型并行等AI分布式训练任务的研究. FlexFlow[33] 一个开源的深度学习编译器和运行时系统，其中提供了一个基于图模型的模块，用于建模与优化分布式AI计算任务. Daydream[34] 使用细粒度的基于图的模型描述分布式训练，主要针对基于all-reduce的分布式并行任务进行建模与仿真. Dpro replayer[35] 基于图模型预测和优化数据并行分布式训练的性能. DistSim[36] 用于预测每个参与分布式训练的算力节点的详细工作时间线. DistIR[37] 一种基于MLIR[38]的中间表示，用于以伪代码的形式模拟分布式训练的执行过程. Proteus[39] 使用策略树描述并行策略，并依赖执行图来建模分布式训练. 该研究考虑了分布式训练的运行时特征. TAG[40] 使用图模型建模并预测分布式训练任务的耗时，同时基于图神经网络搜索并优化分布式训练的执行策略. SMSG[41] 一种无需进行实际性能采集分析（profiling）的分布式训练数学建模方法，仅需输入AI加速器的实际计算性能和系统通信能力，即可对分布式系统中的AI训练任务进行建模. Astra-sim[29,42] 一个帮助研究人员理解并探索分布式训练中多种软硬件协同设计空间的模拟器. 然而，这些已有的研究对于异构计算与一致性互连技术的支持能力较为有限. 具体而言，现有工作面临的主要问题包括以下4点：
1）通常假设所有算力的计算能力一致，难以模拟异构算力差异对计算系统性能的影响.
2）依赖于在特定硬件上运行AI模型训练的前几个训练步骤，并通过性能分析工具获取执行轨迹，导致应用成本较高，无法适用于尚未实际部署的计算系统.
3）对于计算系统中互连拓扑建模的灵活性较弱，无法描述异构一致性融合计算系统中复杂的互连架构.
4）缺乏对一致性建模仿真的支持，无法建模一致性条件下AI计算任务的工作负载与执行方式.
由此可见，现有的建模仿真研究难以解决上述拓扑架构建模困难和引入一致性后计算负载建模困难的两大挑战，难以实现对异构一致性融合计算系统的性能建模，也无法在缺乏实际软硬件的情况下评估系统优化方案的效果. 这些正是本文研究所提出的HCSim所要解决的问题.
1.3 相对精度的系统性能建模
随着计算系统的变量、规模和复杂性逐渐增加，保证性能建模与仿真工作高精度的技术难度不断提升，搭建实际计算系统软硬件平台对仿真器进行校准的成本也在逐步增加，这使得建模与仿真工具的设计与实现变得愈加困难. 因此，近年来，许多建模与仿真工作不再专注于提升仿真的绝对精度，而是更多地关注模拟计算系统的功能与原理，并输出用于参考的相对指标.
例如，SMSG[41]在其研究中指出，重要的不是估计分布式训练的实际执行时间，而是对比不同策略的相对执行耗时. 在Scale-sim[43]仿真器中，研究人员仿真了脉冲阵列微架构[44]的工作流程，但其仿真器仅输出了仿真中定义的周期（cycle），并没有将仿真输出结果与真实系统进行对比. 同样地，在近期提出的Astra-sim[29,42]中，研究者也仅使用仿真中定义的时间对比了不同计算系统软硬件协同设计方式的差异，未探究仿真器建模的具体精度.
对于异构一致性融合计算系统的性能建模与仿真，由于异构软硬件之间通常存在兼容性问题，实际部署计算系统并对仿真进行校准需要付出巨大的工程量与成本，这与建模仿真的初衷相悖. 因此，与诸多近期的研究工作一致，本文研究提出的HCSim采用相对精度，旨在对比不同算力与内存的互连架构、任务负载的部署方式、互连拓扑时延带宽等多种变量对系统性能的相对影响，从而为异构一致性融合计算系统的设计与优化提供指导建议.
2. HCSim的设计实现与工作原理
HCSim的建设目标是对异构一致性融合计算系统的性能进行建模，解决以往建模仿真工作对该系统进行建模的挑战. 根据输入的计算系统互连架构和AI计算负载，HCSim用于模拟仿真AI计算负载的执行流程，最终输出AI计算负载在计算系统中的执行耗时和运行轨迹，为研究者在异构一致性融合计算系统的设计与优化过程中提供相对指标的参考.
2.1 HCSim的架构
为了实现上述目标，本文研究提出HCSim的系统架构如图1所示，主要包括3个核心层的设计：
1）平台层. 用于接收和解析用户输入的异构一致性融合计算系统的互连拓扑配置，并支持用户对互连拓扑以及拓扑中的算力、内存节点进行自定义，进而对算力节点、内存节点、拓扑结构以及节点之间的互连进行建模与仿真.
2）负载层. 接收用户定义的AI计算任务描述，并将计算任务转化为HCSim所定义的负载图，用于描述计算系统中的分布式AI计算任务. 随后，负载层根据转化后的负载图，驱动执行层对计算任务的执行过程进行仿真模拟，并在执行过程中不断输出细粒度的执行轨迹.
3）执行层. 在负载层的驱动下，执行层用于仿真AI计算负载在平台层所定义的计算系统中的执行过程. 该层基于SimGrid[17]实现，包括通信建模和计算建模2个部分，能够模拟算子级别的执行流程，输出AI计算任务的细粒度执行耗时.
HCSim依赖于这3层的相互协作，实现对异构一致性融合计算系统的性能建模.
2.2 异构一致性融合计算系统的拓扑架构建模
为了满足对异构一致性融合计算系统拓扑架构进行建模的需求，HCSim的平台层支持灵活自定义算力节点、内存节点和互连拓扑，并支持定义相关的核心参数. 平台层所定义的互连拓扑会被传递至执行层所集成的SimGrid仿真器[17]，从而实现计算系统互连拓扑的模型构建.
与绝大多数建模工作类似，HCSim仿真平台采用图的方式对互连拓扑进行建模. 表2展示了HCSim在平台层支持构建的图节点与边等元素，以及它们相应的属性参数. 在HCSim中，所构建的图上的节点分为交换节点、异构算力节点和内存节点. 其中，交换节点主要用于描述计算系统中的数据交换节点，如PCIE Switch，NVSwtich，L1 Switch，ToR Switch等，其节点上没有必要的属性. 异构算力节点用于描述计算系统中的异构算力，这些节点需要定义与计算能力相关的属性信息. 对于内存节点，HCSim支持定义内存的容量，也可以将内存设置为无穷大. 对于所构建图中用于连接节点的边，在HCSim中设计用边来表示节点之间的物理链路连接，因此需要定义带宽、时延等与数据传输相关的属性信息.
表 2 拓扑图的元素定义Table 2. Element Definitions of Topology Graph元素名称 属性名 属性含义 交换节点 无需定义属性 异构算力节点 fp16算力/ FLOPS fp16计算精度下的计算性能 fp32算力/ FLOPS fp32计算精度下的计算性能 内存节点 内存容量 包含可用的内存空间有多少 边 时延 所连接节点之间的通信时延 带宽 所连接节点之间的通信带宽 基于平台层的设计，图2展示了HCSim可以构建的异构一致性融合计算系统拓扑的抽象表示. 在一致性互连技术的帮助下，对于任意异构算力（图2中的XPU），不仅可以直接以高带宽低时延访问本地主存，还可以通过一致性互连网络直接访问远端其他XPU的内存或扩展内存，实现缓存一致性. 在图2中，HCSim可以自由修改计算系统和一致性互连网络的互连拓扑，也可以自由定义每个异构算力节点的计算能力、每个内存节点的存储容量，从而实现对异构一致性融合计算系统拓扑架构的灵活建模. 另外，值得注意的是，HCSim对异构算力的定义要求较低，这使HCSim不仅可以建模常用的异构算力，而且可以对诸如FPGA，ASIC等定制化算力进行性能建模. 研究者只需通过测试的方式获得异构算力的计算能力、内存容量等信息，便可以利用HCSim对不同的异构算力开展建模仿真.
2.3 一致性系统中的AI计算负载建模
在异构一致性融合计算系统中，由于XPU可以直接对非本地内存进行访存操作，因此AI计算负载的工作方式与传统非一致性计算系统存在差异，这也导致以往的建模仿真工作难以直接应用.
以往绝大多数建模仿真工作并未考虑内存对计算负载的影响. 即便较新的Astra-sim 2.0[29]提出了面向分离式内存的负载模型，它仍然难以有效描述异构一致性融合计算系统下的负载计算流程. 图3（a）展示了基于Astra-sim 2.0的负载模型构建的计算任务负载图，其中描述了2个异构算力采用数据并行训练带有3个神经层的神经网络. 在图3（a）中，每个顶点代表一个执行过程，边代表执行过程之间的依赖关系，即对于图中的任一个顶点，只有所有指向该顶点的顶点完成后，该顶点才能启动执行. 图3（a）中灰色顶点代表访存的通信过程，黄色顶点代表计算过程，蓝色顶点代表集合通信过程，FP代表前向传播，BP代表反向传播，FP1代表第一个神经层的前向传播过程，以此类推. 可以看出，尽管Astra-sim 2.0考虑了访存过程对AI计算任务的影响，但其建模中仍然仅模拟了将远端内存搬运到本地显存，再进行计算的过程，这与一致性系统的实际情况不符.
![]()
图 3 HCSim中异构一致性融合计算系统拓扑的抽象表示Figure 3. Abstract representation of the heterogeneous consistency integrated computing systems topology in HCSim图3（b）和图3（c）分别展示了HCSim的负载层为上述相同AI计算任务在非一致性系统和一致性系统中构建的负载图，其中黄色顶点代表计算过程，蓝色顶点代表通信过程. 在一致性系统中，由于XPU可以直接访问远端内存，因此远端访存过程可以与计算过程形成流水线执行. 在这种情况下，神经层的计算耗时可能会受到异构算力计算能力的限制，也可能会受到访存速度的限制. 因此，如图3（c）所示，HCSim构建的负载图将计算过程与访存过程描述为并行执行，可以近似表达访存与计算的流水执行过程，进而挖掘每个神经层在一致性系统中的性能瓶颈，以实现更准确地表达AI计算负载在一致性系统中的执行流程. 相比之下，3（b）则展示了HCSim所建模的非一致性系统中异构算力先进行内存搬运，再进行主存访存与计算的过程.
表3展示了HCSim的负载图中所有顶点以及可定义的属性. 可以看出，除了需要在负载图中绑定计算顶点和通信顶点的执行位置之外，HCSim的任务负载图与互连拓扑图几乎解耦，这使得HCSim的使用者能够更快捷地定义不同的计算任务负载. 此外，区别于以往建模工作中常用的有向无环图（DAG），HCSim采用有向有环图对AI计算负载进行建模，从而帮助HCSim更准确地模拟AI训练任务反复迭代循环的过程. 对于AI推理计算、分布式数据分析等其他计算负载，使用者也可以在HCSim中用同样的方式进行定义与仿真模拟.
表 3 负载图的元素定义Table 3. Element Definitions in the Workload Graph元素
名称属性名 属性含义 计算
顶点计算量/ FLOPs 该计算顶点所代表的计算任务的计算量 访存量 该计算顶点所执行的任务需要的访存数据量 执行位置 该计算顶点所执行的异构算力位置 是否为起始顶点 该计算顶点是不是计算任务的起始顶点 通信
顶点通信量 该通信顶点的总通信量 通信方式 该通信顶点的通信方式（例如集合通信、点对点通信） 通信范围 根据通信顶点的通信方式，定义源节点、目的节点，或通信节点范围等 是否为起始顶点 该通信顶点是不是计算任务的起始顶点 连接顶
点的边是否需要在第1次执行考虑 在计算任务第1次执行迭代时，不需要考虑有些边到顶点执行的依赖关系中 2.4 HCSim的工作流程与实现方式
基于构建的互连拓扑和负载图，HCSim可以对分布式AI计算进行建模与仿真. 整体的工作流程如图4所示，图中展示的每个具体步骤以及实现方式将在本节中逐一进行介绍.
1）互连拓扑图与负载图生成
如图4中的①所示，为了构建2.2节和2.3节中描述的互连拓扑图和负载图，HCSim在负载层和平台层分别构建了负载图描述与生成模块、互连拓扑描述与生成模块，并集成了NetworkX[45]的接口. NetworkX是一个非常实用的Python库，专门用于创建、操作和研究图与网络. 该库提供了丰富的功能，使得用户能够方便地构建有向图或无向图，添加或删除节点和边，或为这些节点和边赋予属性. 此外，NetworkX还支持多种图的遍历算法，如深度优先搜索和广度优先搜索，这使得在复杂的网络结构中查找路径、修改路由等方面变得更加简便. 另一个优势是，NetworkX提供了与Matplotlib集成的绘图工具，使得使用者能够将构建的网络拓扑可视化，从而直观地验证所构建的拓扑是否符合需求. 借助NetworkX，HCSim的使用者只需按照表2和表3的要求定义图与属性，即可将所生成的互连拓扑图、负载图作为HCSim建模与仿真的输入.
2）NetworkX-SimGrid拓扑编译
NetworkX本身只能进行图的构建与分析，并不具备仿真能力. 因此，如图4中的②所示，HCSim在平台层进一步构建了NetworkX-SimGrid编译器，使得NetworkX构建的图模型能够被SimGrid加载，并通过SimGrid-S4U[18]模型进行仿真执行.
具体来说，NetworkX-SimGrid编译器的功能是遍历NetworkX所生成的图模型中的节点和边，并将它们逐一转换为SimGrid支持的XML文件格式. 同时，编译器还会使用NetworkX中的Dijkstra算法计算所有节点之间的最短路径，并将这些最短路径作为路由信息，与图模型一同存储为SimGrid可读的XML文件. 此外，路由信息也可以由用户自行定义，从而进一步提升仿真的灵活性.
3）负载执行引擎
如图4中的③所示，在HCSim的负载层中，负载执行引擎的作用是结合所构建的负载图，驱动执行层进行仿真，从而完成对AI分布式计算任务的模拟执行.
具体而言，负载执行引擎采用事件驱动的方式进行仿真. 如图5所示，负载执行引擎首先将负载图中的所有起始顶点（表3中定义为起始顶点的所有顶点）放入一个执行容器中，并启动这些顶点的执行，将其送入执行层进行仿真. 如果执行顶点是计算顶点，该顶点的计算任务信息将被发送到执行层的计算模型进行仿真；如果执行顶点是通信顶点，该顶点则会被发送至执行层的网络模型进行仿真. 随后，负载层还包含一个事件触发器. 一旦执行容器中的某个顶点完成计算或通信，事件触发器会被激活，从执行容器中移除该完成的顶点，并检查该完成顶点在负载图中所指向的所有顶点是否满足所有依赖. 如果有满足所有依赖条件的顶点，这些顶点将被加入到执行容器中. 这样，负载图便可以在执行容器中不断循环执行，并根据仿真平台使用者定义的执行迭代次数生成相应的执行轨迹，直到所有初始顶点被重新加入容器的次数达到定义的迭代次数. 最后，负载执行引擎将收集并汇总整个模拟执行过程，并将分布式AI计算的执行时间与执行轨迹返回给仿真平台的使用者.
4）执行层的计算与网络顶点仿真
如图4中的④所示，当接收到计算顶点或通信顶点的信息时，执行层需要结合平台层的信息对这些顶点进行模拟. 对于计算顶点，HCSim直接使用SimGrid中的计算模型进行耗时计算，即：
tcomp=FLOPsFLOPS, (1) 其中，FLOPs（floating point operations）是计算顶点的浮点运算次数，FLOPS（floating point operations per second）是计算顶点所分配的异构算力的计算能力. 对于通信节点，HCSim采用SimGrid的CM02模型[46]，并设置TCP-gamma为0，从而获得经典的通信耗时模型：
tcomm=tlatency+LdatasizeHbandwidth. (2) 值得注意的是，以上所有SimGrid模型均采用线性最大-最小求解器进行模拟，即不断根据输入到仿真器中的执行任务的执行速度和剩余工作量计算最早完成的操作，并更新求解器与其他未完成的执行任务. 基于这种仿真方式，SimGrid可以更好地权衡仿真精度与仿真速度，从而高效地仿真分布式计算系统的执行流程.
一旦有顶点执行完毕，执行层会转发SimGrid输出的完成信息，并将其反馈给负载执行引擎的事件触发器. 最终，负载执行引擎根据收到的反馈信息，输出AI计算任务的执行时间与执行轨迹，完成对异构一致性融合计算系统的性能建模.
3. 仿真与分析
借助HCSim的仿真能力，本节从计算系统互连架构、异构算力分布、任务规模，以及计算系统互连拓扑的时延、带宽等参数出发，研究与分析了异构一致性融合计算系统的构建方式与性能瓶颈. 随后，针对异构一致性融合计算系统的通信瓶颈问题提出了优化方法，并使用HCSim仿真验证了该优化方法的效果.
3.1 仿真配置
1）互连拓扑配置
为了更好地对比与分析引入一致性数据访问之前计算系统的局限性，以及引入一致性数据访问后计算系统的优势，仿真首先构建了传统未引入一致性数据访问的互连拓扑. 如图6（a）所示，在构建的传统互连拓扑中，服务器内的互连架构借鉴了IEIT 5468服务器的架构[47]. 该架构采用Balance拓扑，每颗CPU下连接1个PCIe switch，每个PCIe switch连接4块异构算力（XPU）. 此外，考虑到诸如英伟达等厂商提供了NVSwitch[48]等高效的异构算力互连能力，本文研究在该拓扑中引入了XPU switch，以表达算力间的高效互连能力. 基于XPU switch，服务器内的异构算力之间可以实现比PCIe switch更强大的互连互访能力. 对于服务器之间的互连架构，整体计算系统的拓扑采用leaf-spine架构. 具体来说，所有服务器对外的互连采用以太网互连，且同一个机架上的所有服务器会被连接到机顶交换机（ToR switch）上. 所有机顶交换机最终连接到一个核心交换机（Core switch）上，从而实现所有服务器和异构算力之间的互连互访. 由于缺乏一致性互连技术，扩展内存只能与服务器中的CPU互连. 本文研究构建了包含
4096 个XPU的计算系统，其中共有32个ToR，每个ToR包含16个服务器，每个服务器中挂载8个XPU，并设定每个ToR内的128个XPU类型相同.![]()
图 6 未引入一致性互连技术与引入了一致性互连技术CXL的互连拓扑架构图对比Figure 6. Comparison of interconnect topology without and with the introduction of the consistent interconnect technology CXL在图6（a）的拓扑基础之上，进一步构建了图6（b）所示的引入一致性数据访问技术CXL[49-51]后的互连拓扑. 该拓扑与图6（a）中拓扑的主要区别在于，该拓扑中额外引入了基于CXL 3.0[15]特性的CXL switch，构建了一致性互连网络（CXL Fabric），用于建模一致性数据访问. 在该系统架构中，一致性互连网络不仅为异构算力之间（CXL Type 2设备）的内存互访提供了快速通路，而且为异构算力提供了额外的内存扩展（CXL Type 3设备）. 如图6所示，所有通过蓝色箭头连接的内存设备之间都可以使用高速的CXL链路进行一致性访问. 此外，由于CXL switch具备级联能力，因此每个机架中的CXL switch 还可以进行级联扩展. 本文研究基于CXL 3.0的能力，将
4096 个XPU通过CXL switch互连. 外置的扩展内存也可以直接连接到一致性互连网络中，供XPU使用.为了公平对比图6（a）与图6（b）的拓扑，仿真中设计为2个拓扑中的每个XPU都配置了可以无阻塞访问的扩展内存. 对于未引入一致性数据访问的互连拓扑，如图6（a）所示，仿真配置了CPU与PCIe之间的4条PCIe连接，保证每个XPU有充足的带宽访问CPU下的外置内存. 对于引入一致性数据访问的互连拓扑，如图6（b）所示，仿真为每个XPU都配置了唯一可访问且不冲突的CXL Type 3内存设备. 通过以上配置，在XPU主存不足时，仿真中每个XPU都可以无阻塞地访问扩展内存，并按照负载图的定义执行相应的数据读取等过程.
2）AI计算负载配置
本文研究通过建模与分析异构一致性融合计算系统在处理LLM训练任务时的性能表现评估该计算系统的性能，因此建立了如图7所示的LLAMA2-13B[52]的负载图. 由于训练LLAMA2-13B的主要耗时集中在计算其模型架构中的40个LLaMA decoder，因此该负载图描述了这些LLaMA decoder的并行训练过程. 其中，在XPU本地内存有剩余时，橙色顶点代表在本地内存的计算过程；在XPU本地内存不足时，对于非一致性系统，橙色顶点代表如图3（b）所示的先内存搬运再计算过程，而对于一致性系统，橙色顶点代表如图3（c）所示的直接访问远端内存进行计算过程. 为了构建HCSim的负载图，本文研究根据矩阵乘法、self-attention、layer normalization、concat、dropout、GeLU等神经层的计算特征，估计了如表4所示的每个神经层的计算量和访存量，并将其记录到负载图中相应的计算与通信顶点中，其中本文研究使用FP32训练精度. 然后，结合每个神经层在反向传播过程中所需同步的梯度数据量，将其记录到表示参数同步过程的相应通信顶点中，从而完成了LLAMA2-13B负载图的所有参数配置，使其能够被HCSim读取并用于模拟执行.
![]()
图 7 LLAMA2-13B的分布式训练负载图Figure 7. Workload graph for distributed training of LLAMA2-13B表 4 LLaMA Decoder中每个神经层的计算量与访存量Table 4. Computational Load and Memory Access of Each Neural Layer in LLaMA Decoder神经层 前传计算量/
GFLOPs前传访存量/
GB反传计算量/
GFLOPs反传访存量/
GBlayer norm 可忽略 0.00002 +0.039×b可忽略 0.00015 + 0.156blinear (K) b×195 0.0488 +0.039×bb×390 0.39 + 0.156b linear (Q) b×195 0.0488 +0.039×bb×390 0.39 + 0.156b linear (V) b×195 0.0488 +0.039×bb×390 0.39 + 0.156b self-attention b×312.5 3.242×b b×625 0.234b concat 可忽略 可忽略 可忽略 可忽略 linear b×195 0.0488 +0.039×bb×390 0.39 + 0.156b dropout 可忽略 0.0195 ×b可忽略 0.0195 add 可忽略 0.078×b 可忽略 0.039 layer norm 可忽略 0.00002 +0.039×b可忽略 0.00015 + 0.156blinear b×780 0.195 + 0.039×b b× 1560 1.562GB + 0.39b GeLU 可忽略 0.156×b 可忽略 0.078 linear b×780 0.195 + 0.156×b b× 1560 1.562GB + 0.39b dropout 可忽略 0.0195 ×b可忽略 0.0195 add 可忽略 0.078×b 可忽略 0.156 3）仿真参数
由于现有仿真工作缺乏对异构一致性融合计算系统中互连拓扑、计算负载的合理建模，因此，本文研究的仿真聚焦于探究HCSim本身的仿真能力.
对于拓扑架构和AI计算负载的其他参数，仿真中的设定如表5所示，其中参考了当前构建计算集群的主流性能参数. 对于表5里未标记为变量的参数，在仿真中配置为定值，不会发生变化. 对于标记为变量的参数，如CXL_link的时延、带宽等，仿真中将对其进行调整，用于对比不同参数对系统性能和任务执行效率的影响. 仿真使用的服务器配置了Intel Xeon Platinum 8168 @ 2.70 GHz处理器，内存为DDR4
2666 MHz.表 5 仿真参数设定Table 5. Simulation Parameter Settings异构一致性融合计算系统 LLaMA2-13B任务配置 算力节点 带宽 时延变量 ToR_to_L1 12.5 GB/s 5 μs 训练时每个XPU
输入的batch_size1 NIC_to_ToR 12.5 GB/s 5 μs seq_len 4096 UPI 62.4 GB/s 100 ns 隐藏层维度 5120 PCIE_link 128 GB/s 250 ns 使用算力节点
数量（scale）变量 XPU_link 900 GB/s 100 ns CXL_link 3.2 仿真结果分析
1）对比引入/不引入一致性的计算系统性能
首先，给定CXL_link的带宽与时延分别为128 GB/s和200 ns，本文研究对比了在使用不同数量的算力节点时，引入或不引入一致性的计算系统性能. 本文研究通过整个计算系统每秒处理的batch数量来对比不同参数配置下的系统性能，并针典型的英伟达H100、A100、V100算力，仿真了H100同构计算系统和H100+A100，H100+V100两种异构计算系统. 对于FPGA，ASIC等异构算力的仿真，也可以通过在HCSim中自定义算力节点实现建模仿真. 图8展示了仿真结果. 仿真记录HCSim仅用756.6 s便完成了包含
1024 个算力节点的一个训练迭代的仿真，这也充分说明了HCSim在对异构一致性融合计算系统性能进行仿真时具有优秀的执行效率.![]()
图 8 对比引入/不引入一致性的计算系统性能的仿真结果Figure 8. Simulation result on the computing system performance with and without introducing consistency从图8看出，无论是在同构还是异构的情况下，引入一致性后的计算系统性能明显优于不引入一致性的计算系统性能. 为了分析性能差异的原因，本文研究提取了如图9所示的仿真输出执行轨迹，其中包含了HCSim中每个计算过程和通信过程在完成时的仿真时间. 经过对执行轨迹的分析，以上性能差异的原因主要包括2点：
![]()
图 9 HCSim对同一个算子输出的执行轨迹Figure 9. Execution trace of HCSim for the same operator output①在不引入一致性的计算系统中，一旦XPU本地内存不足，就需要引入额外的内存搬运过程，导致训练耗时增加. 相比之下，从图9（b）的反向传播过程轨迹可以明显看出，由于一致性互连技术CXL的引入，反传过程可以省略如图3所示的额外本地内存搬运步骤，从而节约训练耗时.
②对比图9（a）中的参数同步过程轨迹可以发现，在不引入一致性的计算系统中，参数同步过程明显耗时更长，这是由于在该系统中异构算力节点之间的梯度同步仍需要通过以太网进行，效率较低. 相比之下，如图6所示，引入一致性后算力之间可以通过一致性互连网络进行通信，从而显著提升参数同步过程的执行效率.
另外，值得注意的是，对于H100+A100、H100+V100两种异构计算系统，在节点数量从128增加至256时，计算系统的性能出现了明显跳变. 这应该是由于在每个ToR内的XPU类型相同的仿真条件下，在128个节点以下时，计算系统仍然保持着同构. 而当节点数量从128提升至256时，系统引入了低性能的异构计算卡，降低了系统的整体计算性能. 这个仿真结果充分说明了对于异构计算系统，一味地增加XPU的数量并不一定会带来计算系统性能的提升，还需考虑XPU之间是否存在计算性能的差异.
2）探究带宽对计算系统性能的影响
进一步地，本节探究带宽对异构一致性融合计算系统性能的影响. 仿真采用图6（b）中的互连架构，并固定CXL_link的时延为200 ns，通过修改CXL_link的带宽与算力节点规模，对LLAMA2-13B的并行训练进行仿真，并观察不同计算系统性能的变化. 图10展示了这部分的仿真结果，经过分析可以得到以下结论：
![]()
图 10 带宽对异构一致性融合计算系统性能的影响Figure 10. Impact of bandwidth on the performance of heterogeneous consistency-integrated computing systems①在算力节点规模不变时，随着CXL_link一致性互连带宽的提升，计算系统的性能会逐渐提升，但提升的效果逐渐减缓. 这是因为带宽的提升缓解了带宽瓶颈，直接加速了内存访问与参数同步过程，从而提升了计算系统的整体性能. 而随着带宽的增加，系统的瓶颈逐渐从带宽转移到了算力，最终导致提升效果不再显著.
②在带宽不变的情况下，参与计算任务的XPU数量的增加显著提升了计算系统的性能. 这应该是由于一致性互连为XPU之间带来了高效的通信能力，提升了计算系统的可扩展性.
③引入异构算力同样会带来计算系统性能的波动，导致提升系统带宽的性能收益减弱.
3）探究时延对计算系统性能的影响
固定CXL_link带宽为128 GB/s，本文研究通过修改CXL_link时延与算力节点规模，从而观察不同计算系统性能的变化. 仿真结果如图11所示，经过分析，可以得到以下结论：
![]()
图 11 时延对异构一致性融合计算系统性能的影响Figure 11. Impact of latency on the performance of heterogeneous consistency-integrated computing systems①在时延较小时，时延略微增加并不会影响计算系统的性能. 这应该是由于在时延较小时，时延对通信影响的比重较低，不会明显影响系统性能.
②随着一致性互连时延的增大，特别是在时延大于10 μs后，时延逐渐成为影响系统性能的关键因素. 这是因为参数同步过程中有大量的通信过程，这些过程受时延影响较大，而时延增加时该影响也会更加显著.
③在时延变化时，计算节点数量更多的计算任务会受到更大的影响. 这是由于计算节点较多时，参数同步过程中通信的次数也会随之增加，造成时延的影响更加显著.
3.3 面向异构一致性融合计算系统的通信优化与仿真分析
进一步地，针对异构一致性融合计算系统的通信优化问题，本文研究提出了基于一致性ring-allreduce的通信优化方法，并利用HCSim的仿真能力，验证了所提方法的有效性.
具体而言，在参与分布式训练任务的节点规模较大或模型参数量较多时，由于节点之间需要通过通信同步模型参数，节点之间的通信将影响任务执行效率. 本文研究提出了一致性ring-allreduce，借助一致性系统的特性，降低了参数同步的通信次数，缓解了通信对AI计算任务的影响. 图12展示了传统ring-allreduce和本文研究所提出的一致性ring-allreduce之间参数同步运作流程的区别. 如图12（a）所示，在传统的ring-allreduce中，受制于异构算力节点内存之间访问的隔离（即图12（a）的虚线），每个异构算力节点都需要将同步后的梯度放置到本地内存，才能实现参数同步更新. 对于N个需要同步参数的异构算力节点，总共需要2×(N−1)次通信. 相比之下，如图12（b）所示，一致性ring-allreduce只需要进行(N−1)次通信便可完成梯度同步，减少了一半的梯度同步的通信步骤. 这是因为在一致性系统中，由于XPU之间的内存可以互相访问，因此只需要在一致性系统中保证平均后的梯度存在（即图12（b）的a0+a1+a2、b0+b1+b2、c0+c1+c2），而不再需要使用额外的all-gather集合通信将同步后的梯度发送到所有的XPU内存上.
![]()
图 12 传统ring-allreduce和一致性ring-allreduce的对比Figure 12. Comparison between traditional ring-allreduce and consistent ring-allreduce基于这一思路，本文研究在HCSim中调整了负载图中对ring-allreduce的执行定义，在给定CXL_link的带宽时延分别为128 GB/s和200 μs的情况下，获得的仿真结果如表6所示. 仿真结果表明，虽然一致性ring-allreduce可以提升系统性能，但提升并不显著. 对于整体算力性能较强，或系统规模较大的计算系统，应用一致性ring-allreduce可以带来相对更大的收益. 总结来看，虽然提升的幅度较小，一致性ring-allreduce可以在没有额外性能损失的情况下合理利用一致性互连的特性，实现在异构一致性融合计算系统中提升AI训练任务的执行效率.
表 6 优化前后对比结果Table 6. Comparison Results Before and After Optimization计算系统架构 传统ring-allreduce 一致性ring-allreduce 64个H100 同构 7.98 batch/s 8.12 batch/s 256个H100 同构 31.97 batch/s 32.53 batch/s 128个H100+128个 A100异构 10.65 batch/s 10.71 batch/s 128个H100+128个 V100异构 12.86 batch/s 12.93 batch/s 3.4 仿真小节
针对异构一致性融合计算系统，本文研究利用HCSim的仿真能力，不仅建模分析了引入一致性技术的效果，而且建模探究了一致性互连网络中带宽、时延对系统性能的影响，最终进一步模拟仿真了所提出的一致性ring-allreduce对该系统性能的提升. 这充分说明了HCSim不仅可以用于异构一致性融合计算系统的性能建模，而且可以通过少量修改完成对异构一致性融合计算系统的优化方案验证.
4. 结论与展望
针对新型异构一致性融合计算系统的性能建模和优化困难等问题，本文研究提出了一种全新的建模仿真工具HCSim. 该工具解决了以往研究中异构一致性融合计算系统拓扑架构建模困难和计算负载建模偏差的问题，并集成了SimGrid仿真器，实现了可以对异构一致性融合计算系统进行灵活高效的性能建模与仿真. 本文研究利用HCSim模拟构建了一致性互连拓扑架构，并建模了LLAMA2-13B的训练负载. 基于HCSim，仿真分析了异构算力分布、带宽、时延和计算规模等变量对异构一致性融合计算系统性能和AI计算任务执行效率的影响. 此外，还针对该系统的通信问题，提出了基于一致性ring-allreduce的通信优化方法，并使用HCSim进行了仿真验证. 通过仿真可以看出，HCSim不仅可以低成本、高效地实现对异构一致性融合计算系统的性能建模，而且能够对异构一致性融合计算系统的优化方案进行仿真验证. 在未来，我们将继续扩展HCSim的仿真能力，包括加入对时间局部性、空间局部性等算子的建模以及加入对一致性维护开销的建模以及加入对更多典型互连拓扑建模的支持，并在仿真能力更加完整后进行开源. 希望本文研究提出的HCSim能为工业界和学术界提供低成本的异构一致性融合计算系统性能评估手段，并为未来新型计算系统的仿真建模提供一些新的思路.
作者贡献声明：李仁刚提出了性能建模的核心思路，撰写仿真器核心代码和论文的主要章节；唐轶男修改与校对论文；郭振华提出了一致性ring-allreduce的思路；王丽实现了一致性ring-allreduce的仿真代码；宗瓒进行了实验部分数据的汇总与论文相关部分的撰写；杨广文负责论文的整体指导.
https://github.com/p4lang/behavioral-model -
![]()
图 1 不同网络处理器架构示意图
Figure 1. Illustration of different architectures of network processors
![]()
图 2 Neptune模拟硬件架构示意图
Figure 2. Illustration of simulated hardware architecture of Neptune
![]()
图 6 Neptune顶层模拟架构示意图
Figure 6. Illustration of Neptune top-level simulation architecture
![]()
图 11 3种NP架构在不同数据包中的性能评估
Figure 11. Performance evaluation of three NP architectures in different packets
![]()
图 12 包解析模块测试集中的协议层次示意图
Figure 12. Illustration of protocol hierarchy in the packet parser module test set
![]()
图 14 不同线程数下包处理延时评估
Figure 14. Latency evaluation of packet processing under different thread counts
表 1 Neptune功能验证需要的参数配置
Table 1 Configuration of Parameters Required for Function Verification of Neptune
参数类型 参数 数值 通用参数 时钟频率/MHz 800 PPE内线程数 1 核内内存大小/B 1 024 包缓冲大小/MB 1 单段式架构参数 PPE总数 128 集群数 1 每集群内PPE数 128 多段式架构参数 PPE总数 128 集群数 16 每集群内PPE数 8 
下载: 导出CSV
表 2 不同多段式架构包处理阶段时间占比
Table 2 Time Proportion of Packet Processing Stages for Different Multi-Phase Architecture
数据包类型 多段式-2段
各段时间占比多段式-4段
各段时间占比4O4-Hit 29∶71 28∶54∶0∶18 4O4-Miss 35∶65 35∶65∶0∶0 4O6 29∶71 28∶54∶0∶18 6O4 29∶71 28∶55∶0∶17 6O6 29∶71 28∶55∶0∶17 TCP 16∶84 15∶58∶0∶26 TCP-Pass 52∶48 52∶48∶0∶0 Meter-Drop 20∶80 19∶59∶22∶0 Meter-Pass 17∶83 16∶50∶17∶17 ARP 1∶0 1∶0∶0∶0 ICMP 1∶0 1∶0∶0∶0 Passthrough 1∶0 1∶0∶0∶0
下载: 导出CSV
表 3 不同协议层数下不同包解析模块性能评估
Table 3 Performance Evaluation of Packet Parser Modules in Different Protocol Layers
层次数 PPE平均周期 流水线平均周期 1 16.0 68 2 43.7 68 3 57.0 68 4 66.4 68 5 75.5 68 6 99.5 68 7 115.4 68 8 126.8 68 9 136.8 68 10 146.7 68 11 155.0 68 平均 126.8 68 VXLAN-TCP 120.0 68
下载: 导出CSV
-
[1] Gadre G, Badhe S, Kulkarni K. Network processor—A simplified approach for transport layer offloading on NIC[C]//Proc of the 2016 Int Conf on Advances in Computing, Communications and Informatics (ICACCI). Piscataway, NJ: IEEE, 2016: 2542−2548
[2] Yang Mingran, Baban A, Kugel V, et al. Using trio: Juniper networks’ programmable chipset-for emerging in-network applications[C]//Proc of the ACM SIGCOMM 2022 Conf. New York: ACM, 2022: 633−648
[3] Krude J, Rüth J, Schemmel D, et al. Determination of throughput guarantees for processor-based smartnics[C]//Proc of the 17th Int Conf on Emerging Networking Experiments and Technologies. New York: ACM, 2021: 267−281
[4] 赵玉宇,程光,刘旭辉,等. 下一代网络处理器及应用综述[J]. 软件学报,2021,32(2):445−474 Zhao Yuyu, Cheng Guang, Liu Xuhui, et al. Survey and applications of next generation network processor[J]. Journal of Software, 2021, 32(2): 445−474 (in Chinese)
[5] 鄢贵海,卢文岩,李晓维,等. 专用处理器比较分析[J]. 中国科学:信息科学,2022,52(2):358−375 doi: 10.1360/SSI-2021-0274 Yan Guihai, Lu Wenyan, Li Xiaowei, et al. Comparative study of the domain-specific processors[J]. SCIENTIA SINICA Informationis, 2022, 52(2): 358−375 (in Chinese) doi: 10.1360/SSI-2021-0274
[6] Luo Yan, Yang Jun, Bhuyan L N, et al. NePSim: A network processor simulator with a power evaluation framework[J]. IEEE Micro, 2004, 24(5): 34−44 doi: 10.1109/MM.2004.52
[7] Abdi S, Aftab U, Bailey G, et al. PFPSim: A programmable forwarding plane simulator[C]//Proc of the 2016 Symp on Architectures for Networking and Communications Systems. New York: ACM, 2016: 55−60
[8] Bosshart P, Gibb G, Kim H S, et al. Forwarding metamorphosis: Fast programmable match-action processing in hardware for SDN[J]. ACM SIGCOMM Computer Communication Review, 2013, 43(4): 99−110 doi: 10.1145/2534169.2486011
[9] Moon Y G, Lee S E, Jamshed M A, et al. AccelTCP: Accelerating network applications with stateful TCP offloading[C]//Proc of the 17th USENIX Symp on Networked Systems Design and Implementation (NSDI’20). Berkeley, CA: USENIX Association, 2020: 77−92
[10] Choi S, Shahbaz M, Prabhakar B, et al. λ-nic: Interactive serverless compute on programmable smartnics[C]//Proc of the 40th Int Conf on Distributed Computing Systems (ICDCS). Piscataway, NJ: IEEE, 2020: 67−77
[11] Xi Shaoke, Li Fuliang, Wang Xingwei. FlowValve: Packet scheduling offloaded on NP-based SmartNICs[C]//Proc of the 42nd Int Conf on Distributed Computing Systems (ICDCS). Piscataway, NJ: IEEE, 2022: 347−358
[12] Hypolite J, Sonchack J, Hershkop S, et al. DeepMatch: Practical deep packet inspection in the data plane using network processors[C]//Proc of the 16th Int Conf on Emerging Networking Experiments and Technologies. New York: ACM, 2020: 336−350
[13] Cisco. Cisco Silicon One P100 processor data sheet [EB/OL]. (2021-10-25)[2024-01-18]. https://www.cisco.com/c/en/us/solutions/collateral/silicon-one/silicon-one-p100-processor-ds.html
[14] Vlachos K, Orphanoudakis T, Papaeftathiou Y, et al. Design and performance evaluation of a programmable packet processing engine (PPE) suitable for high-speed network processors units[J]. Microprocessors and Microsystems, 2007, 31(3): 188−199 doi: 10.1016/j.micpro.2006.09.001
[15] 刘思远,任敏华,谷航平. 基于硬件多线程机制的网络处理器微引擎设计[J]. 微型电脑应用,2022,38(2):106−108 Liu Siyuan, Ren Minhua, Gu Hangping. Design of network processor micro-engine based on hardware multi-threading mechanism[J]. Microcomputer Application, 2022, 38(2): 106−108 (in Chinese)
[16] Chole S, Fingerhut A, Ma Sha, et al. dRMT: Disaggregated programmable switching[C]//Proc of the 2017 Conf of the ACM Special Interest Group on Data Communication. New York: ACM, 2017: 1−14
[17] Sundar N, Burres B, Li Yadong, et al. 9.4 An in-depth look at the Intel IPU E2000[C]//Proc of the 2023 IEEE Int Solid-State Circuits Conf (ISSCC). Piscataway, NJ: IEEE, 2023: 162−164
[18] Netronome. NFP−4000 theory of operation[EB/OL]. 2018[2024-01-18]. https://d3ncevyc0dfnh8.cloudfront.net/media/documents/WP_NFP4000_TOO.pdf
[19] Yazdinejad A, Parizi R M, Bohlooli A, et al. A high-performance framework for a network programmable packet processor using P4 and FPGA[J]. Journal of Network and Computer Applications, 2020, 156: 102564 doi: 10.1016/j.jnca.2020.102564
[20] 李韬,杨惠,厉俊男,等. ChipletNP:基于芯粒的敏捷可定制网络处理器架构[J]. 计算机研究与发展,2024,61(12):2952−2968 Li Tao, Yang Hui, Li Junnan, et al. ChipletNP: Chiplet-based agile customizable network processor architecture[J]. Journal of Computer Research and Development, 2024, 61(12): 2952−2968
[21] Ahmadi M, Wong S. A performance model for network processor architectures in packet processing system[C]//Proc of the 19th IASTED Int Conf on Parallel and Distributed Computing and Systems. Calgary, AB, Canada: ACTA Press, 2007: 176−181
[22] Keslassy I, Kogan K, Scalosub G, et al. Providing performance guarantees in multipass network processors[J]. IEEE/ACM Transactions on Networking, 2012, 20(6): 1895−1909 doi: 10.1109/TNET.2012.2186979
[23] Zolfaghari H, Mustafa H, Nurmi J. Run-to-completion versus pipelined: The case of 100 Gbps packet parsing[C/OL]//Proc of the 22nd Int Conf on High Performance Switching and Routing (HPSR). Piscataway, NJ: IEEE, 2021[2024-01-18]. https://ieeexplore.ieee.org/abstract/document/9481797
[24] Wehrie K, Gunes M, Gross J. Modeling and Tools for Network Simulation[M]. Berlin: Springer, 2010
[25] Fan Chengze, Bi Jun, Zhou Yu, et al. NS4: A P4-driven network simulator[C]//Proc of the 2017 SIGCOMM Posters and Demos. New York: ACM, 2017: 105−107
[26] Gao Kaihui, Chen Li, Li Dan, et al. Dons: Fast and affordable discrete event network simulation with automatic parallelization[C]//Proc of the ACM SIGCOMM 2023 Conf. New York: ACM, 2023: 167−181
[27] Ahn J H, Li Sheng, Seongil O, et al. McSimA+: A manycore simulator with application-level+ simulation and detailed microarchitecture modeling[C]//Proc of the 2013 IEEE Int Symp on Performance Analysis of Systems and Software (ISPASS). Piscataway, NJ: IEEE, 2013: 74−85
[28] Ren Pengju, Lis M, Cho M H, et al. HORNET: A cycle-level multicore simulator[J]. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 2012, 31(6): 890−903 doi: 10.1109/TCAD.2012.2184760
[29] Qureshi Y M, Simon W A, Zapater M, et al. Gem5-X: A gem5-based system level simulation framework to optimize many-core platforms[C/OL]//Proc of the 2019 Spring Simulation Conf (SpringSim). Piscataway, NJ: IEEE, 2019[2024-01-18]. https://ieeexplore.ieee.org/abstract/document/8732862
[30] Arashloo M T, Lavrov A, Ghobadi M, et al. Enabling programmable transport protocols in high-speed NICs[C]//Proc of the 17th USENIX Symp on Networked Systems Design and Implementation (NSDI’20). Berkeley, CA: USENIX Association, 2020: 93−109
[31] Wagner J, Leupers R. A fast simulator and debugger for a network processor[C/OL]//Proc of Embedded Intelligence Conf. 2002[2024-03-21]. https://www.researchgate.net/publication/228724737_A_fast_simulator_and_debugger_for_a_network_processor
[32] Koohi M, Bayadi H, Khaless M N. A simulation environment for network processor based on simultaneous multi thread architecture[J]. Indian Journal of Science and Technology, 2012, 5(10): 1−6
[33] Bosshart P, Daly D, Gibb G, et al. P4: Programming protocol-independent packet processors[J]. ACM SIGCOMM Computer Communication Review, 2014, 44(3): 87−95 doi: 10.1145/2656877.2656890
[34] Li Hejing, Li Jialin, Kaufmann A. SimBricks: End-to-end network system evaluation with modular simulation[C]//Proc of the ACM SIGCOMM 2022 Conf. New York: ACM, 2022: 380−396
[35] Netronome. Programmer studio 6.0[EB/OL]. 2016[2024-03-18]. https://d1agld16eywpip.cloudfront.net/media/documents/PB_Programmer_Studio_6.0_rURUo4Y.pdf
[36] Sokolowski J A, Banks C M. Modeling and Simulation Fundamentals: Theoretical Underpinnings and Practical Domains[M]. Hoboken, NJ: John Wiley & Sons, 2010
[37] Shah N, Kurt K. Network processors: Origin of species[C]//Proc of the 17th Int Symp on Computer and Information Science (ISCIS XVII). Boca Raton, FL: CRC, 2002: 41−45
[38] Sun Yifan, Baruah T, Mojumder S A, et al. MGPUSim: Enabling multi-GPU performance modeling and optimization[C]//Proc of the 46th Int Symp on Computer Architecture. Piscataway, NJ: IEEE, 2019: 197−209
[39] Guo Xuan, Mullins R. Accelerate cycle-level full-system simulation of multi-core RISC-V systems with binary translation[J]. arXiv preprint, arXiv: 2005.11357, 2020
[40] Liu Huan, Qiu Zhiliang, Pan Weitao, et al. HyperParser: A high-performance parser architecture for next generation programmable switch and SmartNIC[C]//Proc of the 5th Asia-Pacific Workshop on Networking (APNet 2021). New York: ACM, 2021: 50−56
计量
- 文章访问数: 486
- HTML全文浏览量: 86
- PDF下载量: 365
