企业官网建设流程全解析

手里这台双路服务器空着两个 PCIe 4.0 x16 槽位大半年，一直想找块能压住业务量、又不至于让整机预算爆表的网卡塞进去。挑来挑去，最后落在 Intel E810-CQDA2 上：双口 QSFP28，单口 100GbE，PCIe 4.0 x16 接口，官方定位是数据中心通用、存储、NFV、时间同步都能吃的一条线。到手之后我没有直接上生产，而是拉了一台同型号的服务器做了一轮完整测试——从插槽带宽算账、光模块兼容性、固件版本核对，到 iperf3 打流、RoCEv2 实测、PTP 硬件时间戳比对、SR-IOV 虚拟化验证，前后折腾了差不多两周。

这篇文章就是把这两周的记录整理出来。适合三类人看：一是正在给服务器选 100G 网卡、想搞清楚 E810-CQDA2 到底适合什么场景的采购和架构同学；二是手里已经拿到卡、正准备上机的运维和系统工程师；三是在做服务器虚拟化、分布式存储或者高精度时间同步方案，想评估这块卡能不能扛住的同学。文中所有参数和步骤都来自我自己的实测记录，凡是基于通用经验做的推断，我会明确标出来，你按自己环境的实际情况再核对一遍。

1. 先把型号吃透：E810-CQDA2 到底是一块什么卡

1.1 型号命名规则与硬件规格拆解

Intel 网卡的命名看着像乱码，其实规律挺清楚。E810 是控制器系列代号，代表这一代以太网控制器；CQ 指的是接口形态和速率等级，C 对应 100GbE 级别的 QSFP 接口，Q 是 QSFP 的缩写；DA2 里的 D 表示双口（Dual），A2 是这一代的板型版本。合起来读就是：基于 E810 控制器的、双口 QSFP28、单口最高 100GbE 的 PCIe 网卡。

这块卡的核心规格我列一下，都是上机前必须确认清楚的：双 QSFP28 端口，每口支持 100GbE / 50GbE / 25GbE / 10GbE 多档速率，可以通过 breakout 线缆拆成 4 个 25G 或者 4 个 10G 使用；主机接口是 PCIe 4.0 x16，向下兼容 PCIe 3.0；支持 RoCEv2 和 iWARP 两种 RDMA 实现；硬件时间戳精度达到 IEEE 1588 PTP 的要求，部分 SKU 还带 SDP 接口用于外部时间信号。功能侧还包含 SR-IOV、VMDq、ADQ（Application Device Queues）以及 DDP（Dynamic Device Personalization，动态设备个性化）。

有一点必须提前说清楚：E810 是一个系列，不是一块卡。同一个控制器下至少有双口 100G、单口 100G、双口 25G、四口 25G 等好几种板型，散热片形状、供电、甚至支持的 PTP 能力都有差异。买之前一定要看具体 SKU 的规格书，别看到 "E810" 就下单，我见过有人买回来发现是 25G 版本，白折腾一天。

1.2 和同类卡横向对比，别盲目上 100G

选卡最忌讳只看峰值速率。100G 卡买回来跑不满，最常见的原因不在卡本身，而在插槽带宽、CPU 中断处理能力和交换机端口能力。我把当时考虑过的几个方案做了个对比，你可以参考这个思路。

表格里最关键的一行是主机接口。双口 100G 满载就是 200Gbps 的双向吞吐，PCIe 4.0 x16 的理论带宽大概 256Gbps（单向），刚好够用还留了点余量；如果插到 PCIe 3.0 x16 上，单向只有约 126Gbps，两口同时压满必然成为瓶颈。这个账后面第 2 节还会细算。

1.3 什么场景下这块卡才算花得值

我个人的判断标准是三条：第一，你对单链路带宽的需求确实超过了 25G，并且短期内不打算靠堆端口解决；第二，你的业务对延迟敏感，需要 RDMA 绕过内核协议栈，比如分布式存储、数据库集群、HPC；第三，你有高精度时间同步需求，比如日志审计、交易类系统、工业控制类场景。

如果三条都不满足，只是想让服务器"看起来先进一点"，那我劝你先别上。100G 的隐性成本很高：交换机端口贵、光模块贵、线缆贵、散热压力大、调优要投入人力。我见过太多机房里插着 100G 卡、实际跑着 10G 流量的服务器，纯属浪费。

2. 上机前的硬准备：插槽、散热、模块三件事

2.1 PCIe 插槽带宽的账要提前算清楚

前面说了 PCIe 3.0 x16 会成为瓶颈，这里把计算过程摆出来。PCIe 3.0 每 lane 有效速率 8GT/s，128b/130b 编码，单 lane 有效带宽约 7.88Gbps，x16 就是约 126Gbps。PCIe 4.0 每 lane 16GT/s，同样编码，x16 约 252Gbps。而 E810-CQDA2 双口满载理论吞吐是 200Gbps，加上协议开销、DMA 读写混合、描述符开销，实际需要的带宽还要再留出余量。

结论很直接：想双口跑满 100G，必须插在 PCIe 4.0 x16 的槽位上，而且要确认这个槽位的电气宽度真的是 x16，不是"物理 x16、电气 x8"的假槽位。上机之后用一条命令就能验证：

lspci -vv -s 01:00.0 | grep -E "LnkCap|LnkSta"

输出里LnkSta那一行如果显示Speed 16GT/s, Width x16，说明链路协商正常；如果显示Speed 8GT/s或者Width x8，那就要回头查主板的插槽分配表和 BIOS 里的 PCIe 拆分设置。很多服务器主板会把 x16 槽位按 x8/x8 拆分给两个槽位用，这种情况下单块卡只能拿到 x8 带宽。

还有一点容易被忽略：部分服务器 BIOS 里对 PCIe 链路速率有独立的省电设置，默认可能是"自动"或者"节能优先"，会导致链路协商到 Gen3。上机前建议把 PCIe ASPM 关掉、链路速率锁定为 Gen4，跑完测试再决定要不要放开。

2.2 散热与风道，比性能更容易被低估

100G 光模块是机房里最容易被忽视的热源。一块 QSFP28 的 SR4 模块典型功耗在 3.5W 左右，双口就是 7W，加上网卡本身的功耗（这块卡典型在 20~30W 区间，具体看 SKU 和负载），整体发热不小。更麻烦的是，光模块的热量集中在金属笼子里，如果服务器风道设计不佳，模块温度很容易冲到 70 度以上，触发降速甚至链路抖动。

我的做法是：上机前先确认机箱在该槽位位置有导风罩覆盖，服务器风扇策略不要设成静音模式；上机后用传感器读温度。带 DDM（数字诊断监控）的模块可以直接从网卡侧读到温度：

ethtool -m eth0 | grep -i -E "temperature|temp"

实操心得：如果模块温度长期在 65 度以上，别急着换模块，先看风道。我有一次测出 72 度，查了半天发现是导风罩没卡到位，重新装好之后降到 55 度，问题直接消失。

2.3 光模块和 DAC 的兼容性，这是最容易踩的坑

E810 系列对光模块的挑食程度在圈内是出了名的。控制器固件里维护着一份模块兼容列表，非列表内的模块可能无法点亮，或者能点亮但速率协商异常。常见的表现是 dmesg 里刷出 unsupported module 之类的提示，链路一直处于 down 状态。

务实的做法有三条。第一，采购时直接买"Intel 编码"的模块，很多第三方模块厂商都提供这种编码服务，价格比原厂低不少，兼容性也经过了大量验证。第二，提前把兼容列表要过来，对着自己现存的模块型号核一遍。第三，如果手上已有模块，先小批量上机验证，别一次性整批采购。

线缆类型上，短距离（机柜内）优先用 DAC 直连铜缆，功耗低、延迟低、成本低；跨机柜用 AOC 或者光模块配光纤。这里藏着一个非常经典的坑：不同速率和不同介质对 FEC（前向纠错）的要求不一样，两端 FEC 模式不匹配是链路起不来的头号原因之一。100G 光模块场景通常要求 RS-FEC，部分铜缆和交换机默认走 FC-FEC 或者关闭 FEC。查看和设置方法如下：

ethtool --show-fec eth0 ethtool --set-fec eth0 encoding rs

注意：改 FEC 会让链路重新协商，生产环境操作前务必确认有回滚窗口，最好先在测试机上把两端的 FEC 组合都试一遍，形成记录再动生产。

2.4 固件版本核对，别让版本差异吃掉你一天

网卡固件和驱动之间是有配套关系的，版本错配轻则功能缺失，重则链路异常。上机第一步先做版本盘点，把固件、驱动、DDP 包三个东西的版本都记下来：

ethtool -i eth0 devlink dev info pci/0000:01:00.0 dmesg | grep -i ice | head -30

ethtool -i看驱动版本和固件版本，devlink dev info能看到更详细的分区固件信息（包括 DDP 包版本），dmesg 里的 ice 驱动加载日志会打印 DDP 包加载情况。把这三个值记录到你的资产台账里，以后排查问题会省很多事。

固件更新一般有两条路：厂商提供的 NVM Update 工具，或者走 devlink 在线刷写。后者更现代，但要求驱动和固件版本在支持范围内：

devlink dev flash pci/0000:01:00.0 file ice_comms-x.xx.x.x.pkg

提示：刷固件前一定先备份当前配置和版本信息，刷写过程中不要断电、不要重启。刷完必须冷启动一次（完整下电再上电），热重启有时候固件不会真正重新加载。

3. 驱动落地：Linux 与 Windows 两套环境的差异

3.1 Linux 侧 ice 驱动的安装与参数

E810 在 Linux 下用的是 ice 驱动。主流发行版的内核自带 ice 驱动，但自带版本往往偏旧，功能特性不一定完整。我的建议是优先用发行版内核自带版本，稳定且不用操心签名问题；如果确实需要新特性，再考虑编译厂商提供的源码包。

先确认当前加载的是哪个版本：

modinfo ice | head -20 ethtool -i eth0 lsmod | grep ice

如果内核自带的版本太旧，编译安装的基本流程是下载源码包、make、make install、然后刷新 initramfs 并重启。这里有一个常见的坑：编译出来的模块没有签名，在开启了 Secure Boot 的服务器上会加载失败，日志里会有 module verification failed 之类的提示。要么在 BIOS 里关掉 Secure Boot，要么自己走一遍模块签名流程。生产环境我一般选择前者，但会先跟安全团队确认。

DDP 包是 E810 的特色功能之一，它允许在不更新固件的情况下动态加载协议解析配置，把特定协议的报文处理下沉到网卡硬件。DDP 包默认放在/lib/firmware/intel/ice/ddp/目录下，跟着驱动一起加载。换包之后需要重新加载驱动或者触发 devlink reload：

ls -l /lib/firmware/intel/ice/ddp/ devlink dev reload pci/0000:01:00.0 dmesg | tail -20

注意事项：DDP 包版本和驱动版本要匹配，混用可能导致加载失败。换包之后一定要看 dmesg，确认日志里打印的是新版本号，而不是回退到默认包。

3.2 Windows 侧驱动与设备管理器核对

Windows 服务器的场景主要是文件服务、备份节点、部分测试工具。装完驱动之后，设备管理器里应该能正常识别，网络适配器下会列出两个物理口。这里有个小细节：Windows 可能会把设备识别成"Intel 以太网适配器"的通用名称而不显示具体型号，想确认具体型号要看设备属性里的硬件 ID，或者用Get-NetAdapter看驱动信息。

Get-NetAdapter | Format-List Name, InterfaceDescription, LinkSpeed, DriverVersion

如果出现黄色感叹号或者设备名带"未知设备"，八成是驱动版本不匹配，去官网按具体 SKU 下载对应驱动包，别用系统自带的通用驱动。另外 Windows 侧同样要装厂商的配置工具，用来做端口绑定、巨帧设置、RDMA 开关这些操作，纯靠 PowerShell 有些参数改不了。

如果是做 SR-IOV 把网卡直通给虚拟机，Windows 侧的配置和 Linux 差异很大，建议统一在宿主机侧用 Linux 管理，虚拟机里用 VF 驱动，这样版本管理更省心。

3.3 固件与驱动配套关系速查

我自己整理了一份版本核对表，上机前对着走一遍，能挡掉大部分低级问题。

这张表看着简单，但我实测下来，八成以上的"网卡有问题"最终都落在这七行里的某一行。

4. 性能实测：从打流到 RDMA 再到时间同步

4.1 基线检查与链路参数确认

正式打流之前先做一轮基线固化，把环境参数全部锁定，否则测出来的数据没法复现。我的基线清单包括：MTU 统一设为 9000、关闭网卡节能特性、中断绑定到固定 CPU、关闭防火墙和无关服务、确认 CPU 频率策略为 performance。

ip link set eth0 mtu 9000 ethtool -K eth0 gro on gso on tso on for i in /sys/class/net/eth0/queues/rx-*/rps_cpus; do echo f > $i; done cpupower frequency-set -g performance

中断绑定的处理有两种思路：交给 irqbalance 自动分配，或者手工把每个队列的中断号绑到固定的核上。追求极限性能选后者，追求省心选前者。手工绑定之后可以用/proc/interrupts观察分布是否均匀，如果所有中断都堆在一个核上，那基本可以判定绑歪了。

grep eth0 /proc/interrupts

这一步别嫌麻烦。我遇到过好几次"100G 只跑出 30G"的情况，最后查出来就是中断全挤在一个核上，改完绑定直接翻倍。

4.2 iperf3 打流：参数怎么设，结果怎么看

iperf3 是最常用的吞吐测试工具，但默认参数在 100G 场景下基本跑不出真实水平。默认单线程、默认窗口、默认单流，受限于单个 CPU 的处理能力，通常只能跑到 20~40Gbps。想压满链路，得多流并发加大窗口。

服务端：

iperf3 -s

客户端：

iperf3 -c 192.168.100.2 -P 16 -t 30 -w 4M --json --logfile result.json

几个参数的含义和调法：-P 16是并发流数，从 8 开始往上试，观察吞吐是否随流数增加而提升，直到出现平台期；-t 30测试时长，太短会被 TCP 慢启动影响，建议至少 30 秒；-w 4M是 socket 缓冲区，要配合系统参数一起调：

sysctl -w net.core.rmem_max=268435456 sysctl -w net.core.wmem_max=268435456 sysctl -w net.ipv4.tcp_rmem="4096 87380 268435456" sysctl -w net.ipv4.tcp_wmem="4096 65536 268435456"

结果怎么看？不要只盯着最后那行 summary。用--json输出之后重点看三件事：一是吞吐曲线是否稳定，如果前几秒低后面爬升，说明 TCP 慢启动影响明显，可以延长测试时间；二是重传次数，重传多说明链路或者拥塞控制有问题；三是双向测试（加--bidir）的结果，双向同时压更能暴露瓶颈。

实测经验：双口同时打流和单口打流的瓶颈位置可能完全不同。单口测试时瓶颈大概率在 CPU 单核处理能力和 PCIe 传输路径上；双口同时压满时，瓶颈往往转移到 PCIe 带宽和内存带宽上。我建议单口、双口各测一轮，分别记录 CPU 占用率（用mpstat -P ALL 1观察），这样才能判断瓶颈到底在哪一环。

4.3 RoCEv2 与 perftest 实测

如果你的场景是分布式存储或者 HPC，TCP 打流的数据参考价值有限，真正的重点是 RDMA。E810 支持 RoCEv2，实测要用 perftest 工具集。先确认 RDMA 子系统识别正常：

rdma link show ibv_devices

看到两个设备（每个物理口一个）说明正常。然后是经典的带宽和延迟测试：

# 服务端 ib_write_bw -d rocep1s0f0 -F --report_gbits -D 30 -q 8 # 客户端 ib_write_bw -d rocep1s0f0 -F --report_gbits -D 30 -q 8 192.168.100.2

几个关键点。-F表示允许在非默认端口运行，测试时必加，否则会因为端口占用报错。--report_gbits让结果以 Gbps 显示，比默认的 MB/s 直观。-q 8是队列对数量，从 1 开始加，观察带宽变化。延迟测试用ib_send_lat或者ib_write_lat，重点关注平均值和 P99，平均值好看但 P99 差的情况在实际业务里照样会出问题。

注意事项：RoCEv2 对网络的 PFC 和 ECN 配置有依赖，如果你的交换机没配无损以太网相关参数，可能会看到带宽正常但偶发丢包。测试阶段可以先关掉这些依赖跑裸带宽，评估链路能力；上生产前务必按完整方案配好，重新回归一轮。

4.4 PTP 硬件时间戳与时间服务器比对

这是 E810 相比很多同价位网卡的一个差异点。它支持 PTP 硬件时间戳，也就是说时间戳由网卡硬件在报文收发瞬间打上，避免了操作系统协议栈带来的抖动。对日志审计、交易记录、工业控制这类要求时间一致性的场景，这个能力很值钱。

先看网卡支持哪些时间戳模式：

ethtool -T eth0

输出里如果同时列出 software 和 hardware 的收发能力，说明硬件时间戳可用。然后是跑 PTP：

ptp4l -i eth0 -m -s -f /etc/ptp4l.conf phc2sys -s eth0 -c CLOCK_REALTIME -w -m -O 0

ptp4l负责和上游时间源对时，-s表示作为从时钟工作，-m把日志打到前台方便观察。phc2sys负责把网卡硬件时钟同步到系统时钟，-w表示等 ptp4l 进入同步状态再开始。想确认同步状态，用pmc查询：

pmc -u -b 0 'GET TIME_STATUS_NP'

实测下来，硬件时间戳方案相比纯软件 NTP，在局域网环境里能把偏差压到亚微秒级别，具体数值和网络质量、交换机是否支持透明时钟有关。如果你只需要毫秒级精度，普通 NTP 就够，没必要为了用而用。

我在测试中踩过的一个坑：如果交换机侧没有开启 PTP 相关功能，ptp4l 会一直卡在监听或者未同步状态，日志里刷 timeout。这时候先确认交换机配置，别一味在服务器侧折腾。

4.5 SR-IOV 与虚拟化场景验证

服务器虚拟化是这块卡的主力场景之一。通过 SR-IOV 把物理口切成多个虚拟功能（VF），直通给虚拟机，可以让虚机绕开宿主机网络栈，接近物理网卡的性能。开启方式：

echo 8 > /sys/class/net/eth0/device/sriov_numvfs lspci | grep -i "virtual function" ip link show eth0

创建之后ip link会列出对应的 vf 条目，可以用ip link set dev eth0 vf 0 mac xx:xx:xx:xx:xx:xx给每个 VF 固定 MAC 和 VLAN。然后在虚拟机 XML 或者管理平台里把 VF 的 PCI 地址直通进去即可。

这里有几个实操要点。第一，VF 数量不要一味求多，每个 VF 都要占用队列资源，切太多会导致单个 VF 性能下降，我一般按"每个虚机至少 2 个队列"来估算。第二，开启 SR-IOV 之后，如果宿主机要改物理口参数，需要先清零 VF 数量再改，否则可能失败。第三，虚拟化平台上做热迁移时，VF 直通的虚机通常不支持迁移，需要用绑定（bond）加桥接的方案做折中，这个要提前和平台团队对齐。

5. 问题排查实录：链路、性能、稳定性三条线

5.1 链路起不来怎么查

链路 down 是最常见也最费时间的问题。我总结的排查顺序是：先看物理层（模块、线缆、两端接口类型），再看协商参数（速率、FEC、自协商开关），最后看配置层（VLAN、端口状态、交换机策略）。

第一步先确认网卡侧看到了什么：

ethtool eth0 | grep -E "Speed|Duplex|Link detected" dmesg | tail -50 ethtool -m eth0 | head -20

如果Link detected: no，并且 dmesg 里有模块相关的告警，先怀疑模块兼容性。如果模块识别正常但链路仍然 down，重点查 FEC 和速率是否两端一致。一个很隐蔽的坑是：一端把速率固化成 100G、关掉了自协商，另一端开着自协商，这种组合在某些交换机上会协商失败。处理办法是两端配置风格保持一致，要么都开自协商，要么都固化参数。

5.2 速率跑不满怎么看

速率跑不满的排查我习惯按"从下往上"的顺序走。先看 PCIe 链路有没有降速降宽，这一个原因能解释相当一部分案例；再看中断和队列分布是否均衡；然后看 CPU 是否有单核跑满；最后才怀疑网卡本身。

观察 CPU 的时候不要只看整体利用率，一定要看单核：

mpstat -P ALL 1 10

如果某个核的 softirq 接近 100%，说明中断处理成了瓶颈，需要增加队列数或者调整中断绑定。如果所有核都不忙但吞吐上不去，那问题可能在 PCIe 或者对端设备上。

还有一个经常被忽略的点是内存带宽和 NUMA 亲和性。网卡插在 CPU0 的槽位上，测试进程跑在 CPU1 的核上，数据要跨 NUMA 节点走，延迟和带宽都会受影响。用numactl把进程绑到和网卡同节点的核上，往往能白捡几个 Gbps：

numactl --cpunodebind=0 --membind=0 iperf3 -c 192.168.100.2 -P 8 -t 30

5.3 偶发丢包和长稳测试

短时间的峰值测试不能说明稳定性。我一般会跑至少 8 小时的长稳测试，同时监控错误计数：

ethtool -S eth0 | grep -i -E "error|drop|crc|discard"

重点关注rx_crc_errors、rx_errors、rx_missed_errors这几类。CRC 错误持续增长基本锁定物理层问题（线缆、模块、接触）；missed 错误增长说明软件侧来不及收包，需要加队列或者加大缓冲区；如果只有 drop 增长而 CRC 为 0，那要去看对端是否在限速或者拥塞丢包。

长稳测试期间还要盯温度和功耗。模块温度在长时间高负载下会比短测高不少，如果接近厂商给的阈值上限，就要考虑加强散热或者换低功耗模块。

5.4 问题排查速查表

这张表是我自己踩坑之后一条条攒出来的，遇到新问题就往里加一行，比临时到处翻文档快得多。

6. 长期运维视角的一些观察

6.1 温度、功耗与日志的日常关注点

网卡不像硬盘那样有 SMART 那样的成熟健康度模型，所以只能靠人工盯几个指标。我的日常巡检清单是：模块温度、网卡结温（如果有传感器暴露）、错误计数增量、链路速率是否发生重协商、驱动日志里有没有异常告警。

链路速率的异常重协商特别值得关注。有些故障表现为链路"偶尔掉一下又恢复"，业务侧可能只是觉得偶尔卡顿，但dmesg里会留下链路 up/down 的记录。巡检时顺手 grep 一下日志，能提前发现线缆或者模块的老化趋势：

dmesg -T | grep -i -E "link is (up|down)|ice.*error" | tail -50

功耗方面，如果服务器侧有 BMC 或者 PDU 的功耗采集，建议把网卡上线前后的整机功耗差记下来，作为机房容量规划的输入。我在测试环境里观察到的情况是，双口 100G 满载和空闲状态的整机功耗差是实打实存在的，机房配电做预留时不要漏掉这一块。

6.2 固件生命周期管理和配置固化

网卡的固件不是刷一次就完事。厂商会不定期发布新版本修复问题、增加特性，但盲目跟新同样有风险。我的策略是：只在遇到已修复的具体问题或者需要新特性时才升级，升级前在测试环境跑一轮完整回归，升级后保留旧版本包以便回滚。

配置固化这件事经常被忽略。网卡上的很多参数——MTU、FEC、中断绑定、队列数、SR-IOV 的 VF 数量——重启之后不一定保留。在 Linux 上可以用网络管理工具做持久化，比如把 ethtool 参数写进 NetworkManager 的配置文件，把 sysfs 参数写进 udev 规则或者启动脚本。否则每次重启都要手工配一遍，早晚会出岔子。

# 示例：NetworkManager 连接配置里持久化 MTU 与 ethtool 参数 nmcli con mod eth0 802-3-ethernet.mtu 9000 nmcli con mod eth0 ethtool.feature-gro on nmcli con up eth0

还有一个容易踩的坑：某些固件升级之后，之前的自定义配置会被重置为默认值，包括 FEC 和队列设置。所以升级流程里必须包含"升级后重新核对配置"这一步，我自己的清单里就固定了这一条，吃过一次亏之后就再也没省过。

最后分享两个我个人比较看重的小经验。第一，所有测试数据一定要留原始记录，包括命令行、时间戳、硬件序列号、固件版本，隔几个月回头看问题的时候，这些记录的价值远超你的想象。第二，新硬件上机之前，先用一块老旧的低速网卡把整条链路和交换机端口验证一遍，确认对端配置没问题之后，再换成 100G 卡，这样能把问题范围直接缩小一半，省下来的排查时间远比多插一次卡多得多。