服务器里同时装着 CPU、内存、NVMe 固态盘、网卡和加速卡,但它们并没有共享同样的连接方式。内存通常接在 CPU 的内存控制器上;许多高速外设则通过 PCI Express,简称 PCIe,与处理器系统交换数据。看懂 PCIe,能够解释为什么同样的盘换了插槽会变慢,为什么还有空插槽却装不下新卡,以及为什么扩容加速卡后存储也开始排队。
本课围绕实际机器建立入门模型:先画路径,再算链路上限,随后用观测区分资源不足、连接异常与设备本身的限制。涉及虚拟化时,只讨论设备分配和隔离边界;链路训练细节、协议包字段与复杂一致性机制留待后续课程。
1 PCIe 总线要掌握的传输模型
名字里虽然有“总线”,现代 PCIe 更适合想象成由点对点链路组成的树。CPU 侧的根复合体连接处理器系统与 PCIe 层次,设备可以直接接到根端口,也可以经过 PCIe 交换芯片。交换芯片提供更多下行连接,却不能让上行链路凭空增加带宽。设备之间能否直接交换数据,还取决于平台、驱动与拓扑支持,本课先按设备经过主机内存交换数据来理解。
从主机看,网卡、NVMe 控制器和加速卡都是不同用途的设备端点。操作系统发现设备后,为它分配地址资源,加载驱动,再由驱动配置队列和缓冲区。CPU 可以访问设备映射到地址空间中的寄存器,例如向提交队列的门铃寄存器写值,通知设备有新工作。这里的“写地址”不等于写普通内存:目标由地址映射决定,设备会按自己的接口解释这个动作。
大块数据通常通过直接内存访问,也就是 DMA,移动。以读取 NVMe 数据为例,驱动先准备接收缓冲区,提交包含目标地址与长度的命令;控制器读取介质,再通过 PCIe 把数据写进相应的主机内存。完成信息进入完成队列后,驱动可以通过中断或轮询发现结果。CPU 负责组织工作与处理完成,并不需要逐字节搬运每段数据,但内存与互连仍然要承担真实流量。

“读盘”是应用观察到的方向,“写主机内存”是设备执行 DMA 时的方向,这两种说法可以同时成立。估算吞吐时应明确箭头指向哪里:盘到内存、内存到网卡,还是加速卡到内存。若文件先读入内存再经网卡发出,数据经历了不同设备链路;如果这些链路又汇入同一个上行口,就可能争用同一段容量。不能只把每张卡的规格各看一次。
还要区分内存容量和连接带宽。增加到 256 GB 内存能容纳更多缓存,却不会直接把 PCIe x4 变成 x8。反过来,更宽的插槽也不能保证应用更快:盘内介质、网卡线路速率、CPU 处理能力、内存带宽和软件队列都可能先成为限制。理解传输模型的目的,是把“机器慢”拆成具体路径,而不是给所有性能问题贴上 PCIe 的标签。
可以用 3 个问题检查自己的路径图:命令由谁发出,数据最终落在哪里,沿途哪些链路会被其他设备共享。只标设备名称的配置清单回答不了这些问题。即使没有完整电路图,也应从主板手册、系统枚举结果和设备文档中补齐连接关系;无法确认的连接要标为待核实,避免把猜测写成选型依据。
2 链路、通道与代际带宽
PCIe 的 lane 常被称为通道或通路。每条 lane 包含用于发送和接收的独立差分信号对,因此链路可以同时向两个方向传输。x1、x4、x8、x16 表示链路使用的 lane 数量。这里的 x4 不是 4 个独立设备接口;它表示这条链路聚合了 4 条 lane。若主板支持把 x16 拆成 x4/x4/x4/x4,还需要相应的端口拆分设置与转接板支持,不能只靠机械转接实现。
代际决定每条 lane 的传输速率。PCIe 3.0、4.0、5.0 分别是 8、16、32 GT/s,GT/s 表示每秒传输次数,不是应用每秒得到多少字节。对于这 3 代,可先按 128b/130b 编码计算单方向的编码后容量:传输速率乘以 128/130,再除以 8,最后乘 lane 数量。这里采用十进制 GB/s,1 GB 等于 10^9 字节;这仍然没有扣除协议事务开销。
| 代际 | 每 lane 速率 | x1 编码后容量 | x4 编码后容量 | x16 编码后容量 |
|---|---|---|---|---|
| PCIe 3.0 | 8 GT/s | 约 0.985 GB/s | 约 3.94 GB/s | 约 15.75 GB/s |
| PCIe 4.0 | 16 GT/s | 约 1.97 GB/s | 约 7.88 GB/s | 约 31.51 GB/s |
| PCIe 5.0 | 32 GT/s | 约 3.94 GB/s | 约 15.75 GB/s | 约 63.02 GB/s |
这张表按单方向列出容量。全双工意味着反向也有自己的容量,不意味着单个方向的读盘任务可以把数值翻倍。PCIe 6.0 引入了不同的传输与编码安排,不能直接套用这里的速率换算。入门时先把实际机器上的代际、宽度和方向说准确,比记住所有新标准更有用。

插槽长度也不能代替电气规格。看起来能插 x16 卡的长插槽,可能只接了 x4 信号;有些 M.2 接口连接 CPU,有些连接芯片组;有些接口与 SATA 端口或其他插槽共享资源。服务器还可能通过转接板把 CPU 通道引到不同位置,安装了不同的转接板后,可用槽位会改变。采购清单上的“有 3 个长槽”因此远远不够。
链路建立时会协商双方能共同支持的速率与宽度。PCIe 4.0 x4 的盘接入只支持 PCIe 3.0 的接口,正常结果可以是 8 GT/s、x4;若在预期支持完整连接的槽里只得到 x1,则需要继续查插接、连接器、转接线和平台配置。协商结果必须和路径上的能力一起判断,低于设备最高规格并不自动代表故障。
双路服务器还有位置问题。部分插槽连接 CPU 0,部分连接 CPU 1;只装了 1 颗 CPU 时,另一侧槽位可能无法工作。即使设备可用,进程与内存放在另一颗 CPU 附近,也可能增加跨处理器互连流量。因此“总 lane 数够用”只能作为起点,实际方案还要回答这些 lane 出现在哪些槽位、由哪颗 CPU 提供。
3 事务层、数据链路与物理层直觉
PCIe 把传输职责分成不同层,可以用“要办什么事、相邻两端怎样可靠交付、信号怎样越过连线”来记忆。事务层表达内存读写、配置访问等请求,并用完成消息回应需要回应的请求。它提供的是系统能够理解的操作语义,不只是无区别的字节流。设备寄存器访问和 DMA 数据传输最终都会落到相应事务上,但应用通常通过操作系统与驱动使用它们。
数据链路层负责相邻链路两端的可靠传递,包含差错检测以及必要的重传机制。这个可靠范围是一段链路,不能直接推导成整个应用操作一定完成。物理层则处理电气信号、lane 组合与链路建立等事项。连接器接触不良、走线质量或转接线问题可能在这一层影响可用宽度和速率,并通过上层错误记录表现出来。
用读取设备提供的数据来建立请求与完成的直觉:请求方先发出读请求,响应方返回带有数据的完成消息;多个请求可以在允许的资源范围内等待完成。写操作也不能被统一理解为“每次写都有同样的立即回执”,因为常见内存写事务采用不同语义。这里无需背包格式,只要知道不同操作消耗的链路方向、等待时间和管理资源可能不同。

传输效率与块大小有关。搬运很小的数据时,请求、头部、完成处理和软件调用占比较高;合并成更大的连续传输,通常更容易接近链路容量。设备可以同时处理的未完成请求数量也有限。若每次只允许很少的数据在途,即使链路很宽,等待响应的间隙仍可能让它空闲。这个现象解释了为什么顺序大块测试与小块低队列深度测试会得到不同结论。
流量控制也会让“链路有空”与“现在能继续发”出现差别。接收方需要有接收资源,发送方才能按规则推进,不能向已经满了的缓冲区无限灌数据。入门阶段把它理解成接收能力约束即可,不必深入信用计数和包调度。若软件队列、设备缓冲或下游处理速度有限,链路仪表上没有满载也可能伴随较高延迟。
错误记录应放回分层模型理解。可纠正错误表示某些异常被检测并处理了,反复出现仍值得调查;不可纠正错误可能影响设备可用性,具体后果取决于错误类别和平台恢复行为。没有错误日志也不能证明没有容量瓶颈:一条完全健康的共享链路,同样可能因为流量太大而排队。错误与拥塞需要不同证据。
最后区分命令完成与业务持久化。PCIe 负责连接和传输,存储命令如何保证数据持久化还涉及 NVMe 命令语义、设备缓存与断电保护;网卡完成发送描述符,也不代表远端应用已经处理消息。沿着层次解释保证范围,可以避免把“传过去了”误说成“整个业务已经成功”。
4 动手:估算一块 NVMe 的通道需求
设想要给 1U 服务器安装 1 块 NVMe 盘,目标是在持续顺序读取时让应用得到 6 GB/s。盘的接口能力是 PCIe 4.0 x4,主板有直连 CPU 的 x4 接口,也有经过芯片组的接口。这里的目标是持续读取吞吐,不包含随机写入性能,也不假设盘在所有温度和容量状态下都能持续提供相同速度。先把负载范围写清楚,才有可比较的估算。
先算 PCIe 4.0 每条 lane 的编码后容量:16 × 128/130 ÷ 8,约为 1.969 GB/s。再引入教学用效率系数 η,假设扣除协议与工作负载影响后,能利用编码后容量的 85%。那么每条 lane 的预算约为 1.674 GB/s,6 ÷ 1.674 约为 3.59,需要选择设备与平台支持、且不少于这一需求的链路宽度。对于这块盘,x4 是合适的候选连接。
写成完整检查,就是 7.88 × 0.85 约等于 6.70 GB/s,略高于 6 GB/s 目标;若只能协商为 PCIe 3.0 x4,则估算仅有 3.94 × 0.85,约 3.35 GB/s。前者只说明链路预算允许继续验证,不能保证盘实际达到目标。效率系数也不是 PCIe 标准承诺,真实值要由设备、请求大小和测量结果决定。
接着检查共享段。假如 2 块盘各希望读出 6 GB/s,而它们都经过同一条 PCIe 4.0 x4 上行链路,下行接口分别足够仍然没用:合计 12 GB/s 超过了上行约 7.88 GB/s 的编码后容量。芯片组路径还可能承载网卡、USB 控制器或其他存储设备,需要按具体平台画出共享关系。把盘接到不同插座,不一定改变这个约束。

在有授权的 Linux 机器上,可以先用只读命令核对连接。下面的设备地址是示例,应替换成枚举结果中的实际地址;使用详细信息时,普通用户可能看不到全部字段,应记录这一限制。命令输出格式随系统版本变化,不要照抄示例地址后就认定查到了目标盘。
lspci -Dnn
lspci -t
lspci -s 0000:41:00.0 -vv
重点看目标设备以及相关上游端口的 LnkCap 和 LnkSta:前者表示该端口的链路能力,后者反映当前协商状态。端点显示 x4,并不能证明中间每段上行都足够宽。把设备型号、代际、当前宽度、上游路径、CPU 归属写在同一张记录表里;再核对主板手册中的共享限制,才完成连接层面的检查。
实测还要固定测试文件、块大小、队列深度、并发数与测试时长,并记录盘温度和系统负载。读取已有专用测试文件,先确认文件范围和缓存策略;不要对承载业务的原始设备随手运行写入测试。分别观察单盘与并发读取,若单盘达标而并发合计停在相近上限,共享路径就是重要候选。这里只给出调查方法,不把未执行的测试写成已经得到的结果。
5 SR-IOV 与设备直通边界
虚拟机使用网卡或加速卡时,既可以通过软件提供的虚拟设备,也可能直接接触硬件功能。整设备直通通常把选定的 PCIe 功能交给某台虚拟机使用,来宾驱动能够直接操作它。SR-IOV 则让支持此能力的设备提供多个虚拟功能,简称 VF;物理功能简称 PF,承担设备管理及虚拟功能配置等职责。能创建多少 VF、每个 VF 有哪些能力,必须查具体设备与驱动支持。
“功能”不等于整张物理卡。1 张卡可以暴露多个 PCIe 功能,平台能否安全分开分配,还要看复位影响范围、设备设计和隔离能力。把 1 个功能交给虚拟机后,若复位会同时影响同卡其他功能,运维就必须考虑对邻居的影响。不能只凭系统列出多个设备编号,就断定它们拥有独立的电源、故障和安全边界。
IOMMU 是这里的重要基础。设备进行 DMA 时,IOMMU 可以按配置约束它可访问的内存地址范围,并提供地址转换。操作系统常用 IOMMU 分组表达可安全隔离的设备集合;实际分组与平台拓扑、访问控制能力及内核判断有关。分组过大时,不应为了让界面允许直通,就用覆盖设置假装硬件具备独立隔离能力。显示上分开,不代表访问路径真的被约束。

SR-IOV 的好处是减少部分软件转发路径和设备模拟开销,但多个 VF 仍可能共享端口线路速率、设备内部队列资源与 PCIe 上行容量。例如 1 个 100 Gb/s 端口创建 8 个 VF,不能据此承诺每个 VF 都能同时获得 100 Gb/s。是否有速率限制、带宽保证或队列配额,要按设备实际功能配置,并用多个租户同时运行的情况验证。
直通也会改变维护方式。虚拟机可能依赖特定设备和驱动组合,迁移能力取决于平台与设备支持,不能沿用普通虚拟设备的默认预期。PF 的重置、驱动升级或固件维护,也可能中断关联 VF。选型阶段就要说明谁管理 PF,谁能创建 VF,维护窗口影响哪些虚拟机,以及故障后如何重新绑定设备和恢复业务。
对于入门方案,可以把评审压缩成 3 类证据:资源是否够用,DMA 与控制权限是否受约束,维护和恢复是否可执行。吞吐测试只覆盖其中一部分。IOMMU 不能代替网络访问策略,VF 也不会自动让来宾流量可信;设备隔离与网络隔离需要分别设计。后续学习网络安全时,这种区分会帮助我们避免用性能功能替代安全措施。
6 常见坑:把标称 GT/s 当有效吞吐
最常见的计算错误,是看到 PCIe 4.0 的 16 GT/s,就写成每条 lane 能传 16 GB/s。这个数字描述传输速率,还没有完成编码折算与位到字节的转换;按本课公式,每条 lane 只有约 1.97 GB/s 的编码后容量。再考虑协议与设备工作方式,应用可用吞吐还会降低。算式中每个单位都写出来,比只背一个最终数字更容易发现错误。
还有一种容易混淆的说法:PCIe 4.0 x4 双向合计约 15.75 GB/s,所以顺序读取应该达到这个数值。双向合计描述两个方向同时工作时的容量总和,不能全部分给盘到主机内存的单向数据。读请求与完成数据可能使用不同方向,但这并不把大块读取的主要数据通道变宽。报告结果时,应注明测量方向和是否汇总双向流量。
单位也可能制造看似异常的差值。链路估算通常用 GB/s,系统工具可能用 GiB/s;1 GiB 等于 2^30 字节,6 GB/s 约为 5.59 GiB/s。二者不能直接比较数值大小后就认定损失了性能。网络端口标注的 Gb/s 又是位速率,例如 100 Gb/s 除以 8 是 12.5 GB/s,实际应用数据还要扣除相关协议开销。
带宽与延迟回答不同问题。每秒能搬很多数据,不表示单次请求会很快完成;小块随机读取还要看设备介质、控制器、请求排队与软件路径。例如每次读取 4 KiB、每秒完成 100000 次请求,数据量约为 409.6 MB/s;这个吞吐远未接近 PCIe 4.0 x4 上限,却可能已达到当前负载条件下的设备能力。不能只因链路未满就判断测试有错。
缓存也会掩盖路径。应用重复读取的数据若来自主机内存缓存,测到的是包含内存访问的软件路径,不是 NVMe 持续读取介质的速度。设备写入缓存则可能让短时写入很好看,持续运行后下降。任何性能结论都应写清数据集大小、读写方式、持续时间和缓存条件;否则“实测比理论还快”通常只说明测量对象与计算对象没有对齐。
最后不要把所有降速都归给带宽。设备高温降频、供电不足、驱动异常、链路重传、CPU 忙于处理中断,都可能造成速度下降。带宽瓶颈通常要结合路径上限与并发变化判断;错误问题要看日志与链路状态;温度问题要看时间趋势与传感器记录。把这些证据分开保存,才能在更换插槽或调整负载后判断究竟改变了哪个因素。
7 案例:通道争用拖垮加速卡
下面是用于推理的服务器案例,数字是教学设定。某台 2U 服务器在 1 个 PCIe 4.0 x16 上行口后连接了交换芯片,下挂 1 张加速卡、1 张 100 Gb/s 网卡和 2 块 NVMe 盘。每个设备单独测试都正常,但训练任务同时读取数据并接收网络输入后,加速卡利用率出现明显起伏,任务完成时间增加。运维最初怀疑加速卡计算能力不够。
先把工作拆开:加速卡不断从主机内存读取输入,假设希望得到 20 GB/s;网卡持续把接收数据写入主机内存,观测约为 10 GB/s;2 块盘同时向内存写入读取结果,各需要约 6 GB/s。加速卡读内存的数据主要占用上行链路的下行方向,网卡和盘写内存则主要占用上行方向。所有设备带宽直接求和,会把不同方向混在一起。
在这个设定中,上行方向的主要数据合计约为 22 GB/s,尚未仅凭数值超过 PCIe 4.0 x16 约 31.51 GB/s 的编码后容量。因此不能看到共享交换芯片,就宣判上行带宽不足。调查继续发现,实际转接板只为该位置接入了 x8,当前协商宽度也是 x8,单方向编码后容量约为 15.75 GB/s。此时 22 GB/s 的上行需求才与真实容量产生明显冲突。

接下来进行可比较的对照:保持加速卡任务与数据规模一致,分别运行加速卡单独负载、加速卡加网络输入、加速卡加存储输入,以及全部并发。记录各设备吞吐、加速卡等待输入的时间、链路协商状态和错误计数。若并发时盘与网卡合计吞吐趋于同一上限,且去掉其中一类流量后另一类恢复,就支持共享上行容量不足的解释。
同时查看温度、功耗限制和 CPU 负载,避免把同期发生的变化都算给 PCIe。若观测到链路错误持续增长,调查方向还需扩展到转接板、插接与信号质量;若宽度正确、错误稳定,而输入处理线程已经占满 CPU,则应优先分析软件与计算资源。诊断结论要允许被证据推翻,不能让最初的拓扑猜测控制所有后续解释。
处理方案可以是把部分设备迁移到另一个独立根端口,或选择真正提供 x16 上行的槽位与转接板。调整输入批次、限制后台复制并发,也可能在不换硬件的情况下减少峰值争用,但它改变的是负载安排。最终复测要保留同样的数据规模和并发条件,确认任务完成时间与输入等待确实改善,并检查新路径是否把瓶颈转移到了其他共享资源。
8 把 PCIe 拓扑写进服务器选型
服务器选型不应止于“支持多少块盘、多少张卡”。先列出每个设备的接口代际、所需宽度、持续吞吐方向、峰值并发条件和安装位置,再标明连接 CPU、交换芯片或芯片组。对于多路机器,补上 CPU 归属与内存分配计划。这样采购与运维看到的是能够复核的路径,而不只是设备型号堆成的清单。
不同机器形态会改变可实现性。紧凑型主机可能只有 1 个扩展槽,且 M.2 与其他端口共享资源;1U 服务器常依靠转接板改变卡的安装方向;2U 服务器虽然有更多机械空间,也可能受到通道、散热和供电限制。全高、半高、卡长、槽宽与辅助供电都应核对,不能把“电气上能连接”直接等同于“可以稳定装进这台机器”。
盘位背板同样需要确认。外观相似的盘位可能支持不同接口,是否能接 NVMe、由什么线缆与控制器承载,应以背板和整机配置文档为准。热插拔能力也由设备、槽位、平台和软件共同支持,不能因为连接器方便拔出就视为允许在线更换。选择前明确维护步骤,比交付后才发现必须停机更容易控制成本。
带宽预算按共享段分别计算。给每段写出单方向容量,再填入同时通过该段的主要数据流;为协议开销、突发与未来扩容保留余量,但不要把固定余量百分比当作所有机器通用的标准。若负载指标尚不清楚,应把“需要实测确认的并发组合”列为验收条件,而不是用标称峰值直接承诺应用吞吐。
还要考虑故障影响范围。交换芯片或共同上行路径失效,可能同时影响多块盘与网卡;将冗余设备接在同一共享部件下,可能保住设备数量却保不住服务。是否需要不同根端口、不同 CPU 路径或独立机器,应由可用性目标决定。增加独立路径后仍要确认软件能够切换,硬件有 2 条路并不自动带来业务恢复。
验收可以围绕可观察的结果安排:核对全配置下的链路速率与宽度,跑计划中的并发组合,记录温度和错误趋势,确认维护动作的影响范围。虚拟化场景再补充 IOMMU 分组、VF 分配与复位行为。报告注明整机配置、固件和驱动版本,避免同型号机器更换转接板后继续沿用旧结论。后续扩容时,这份记录就是判断新增设备能否接入的依据。
9 从 PCIe 走向网络安全基础(S38)
PCIe 讨论的不只是快慢,也包含“谁被允许访问什么”。设备能 DMA 到主机内存,虚拟机能控制某个 VF,管理程序能重置 PF,这些都是带权限的能力。若只关注带宽,把设备视为永远可信的搬运工具,就会忽略错误配置、设备漏洞或不当分配带来的影响。下一课进入网络安全基础时,可以沿用这种从能力与边界出发的观察方法。
先画出资产:业务数据位于哪段内存,哪些盘保存持久数据,哪些网络接口连接外部系统;再画主体:宿主机、来宾系统、设备和管理人员;最后把允许的访问标到路径上。IOMMU 约束设备内存访问,虚拟机分配规则限制控制权,网络策略决定允许到达的通信目的地。它们分别处理不同层面的权限,需要协同而不能互相替代。
例如租户虚拟机获得网卡 VF 后,直通减少了部分宿主机软件路径,但并不意味着它发出的报文自动符合业务访问规则。网络隔离、地址分配和入口控制仍需落实。同样,链路没有错误、吞吐达到目标,也不能证明虚拟机无法接触其他租户的数据。性能验收与权限验收应有各自明确的问题和证据,最后共同支持交付决定。
故障与攻击的症状还可能相似。某个 VF 占满共享带宽,会让其他任务延迟增加;可能只是批量任务并发,也可能是失控程序持续发送。先确认流量来源、时间范围、配额和共享路径,再结合操作记录判断原因。不能只凭“突然变慢”就认定受到攻击,也不能因为硬件健康就排除滥用。可观察性让两类调查都有落脚点。
可以把本课记录表转成安全提问:谁有权把设备交给虚拟机,谁能修改 VF 配置,设备故障会影响哪些服务,日志能否关联到实际使用者。对于不需要的直通能力和管理入口,应按实际业务收紧权限。这里先建立最小权限和影响范围的直觉,不展开复杂攻击手法;S38 会进一步说明如何识别威胁、控制暴露面并形成可执行的防护措施。
放进方案里
为 1 台承载数据处理任务的 2U 服务器编写方案时,先把目标写成可验收的负载:2 块 NVMe 各持续读取 6 GB/s,网卡接收约 10 GB/s,加速卡在指定任务中获得稳定输入。注明这些数值是否同时发生、分别指向哪里,以及测量采用 GB/s 还是 GiB/s。不要只写“高性能存储与高速网络”,否则无法判断设备组合是否满足需求。
附上实际拓扑图,将 CPU、内存归属、根端口、交换芯片、转接板、背板与设备逐层连接。每段链路注明代际、宽度和单方向容量,给同时经过的流量做预算。设备能力与当前协商状态分栏记录;尚未拿到整机时,用文档确认值并标注待验收项。插槽共享、CPU 安装条件、散热和供电限制也要进入配置清单。
如果提供设备直通或 SR-IOV,写清 PF 管理者、VF 使用者、IOMMU 隔离条件和复位影响范围,并规定维护窗口。冗余路径应说明共同依赖哪些部件,故障后由什么机制切换,不能只以设备数量证明可用性。扩容计划应给出可用槽位及其上游余量,而不是承诺所有空槽都能满速工作。
交付验收保留单设备与并发负载的对照记录,检查吞吐、任务延迟、链路状态、温度和错误趋势。并发测试应在温度稳定后持续 30 分钟,按约定采样窗口核对各盘读取是否达到 6 GB/s;加速卡输入等待时间的上限由任务基线确定。保存端点及上游端口的链路状态、测试前后错误计数与带时间戳的吞吐记录。若出现链路降宽、降速或不可纠正错误,即使平均吞吐达标也应暂停验收并查明原因;可纠正错误持续增长时,应检查插接与信号路径后复测。若结果不达标,先按路径定位,再决定调整设备位置、并发安排还是整机配置。将通过条件、配置版本、已知限制和恢复步骤一起交给运维,使下次加盘、换卡或升级驱动时能够重做有针对性的检查。
10 小结:下一步网络安全基础(S38)
理解 PCIe,要同时掌握路径、容量和权限:设备经哪些链路到达内存,代际与宽度能提供多少单方向容量,共享和隔离又在哪里生效。标称 GT/s 是计算起点,当前协商状态与真实并发负载才决定是否满足使用目标。
自测时可以回答这 3 个问题:PCIe 4.0 x4 的盘接在 PCIe 3.0 x4 路径上,应该按哪段容量估算?设备单独运行正常、并发时变慢,需要补充哪些拓扑与方向证据?创建多个 VF 后,哪些资源和维护动作仍然共享?能够给出理由,就可以把同样的边界思维带到 S38:先识别资产、主体和访问路径,再选择具体安全措施。