我有两台服务器，安装了启用了双 RDMA 的 25GbE NIC。目前，在测试期间，它们是直接连接的……它们之间没有交换机。如果我只在它们之间建立单个 SFP28 连接，我可以轻松使 25GbE 链路饱和。但是，当我设置第二个时，我最多可以达到 35Gbps，而不是所需的 50Gbps。
不想让您感到无聊，也不想详细介绍所有配置细节……我已经确定，在单个 25GbE 连接期间，SMB 多通道会自动为连接分配 4 个通道，这足以使 4 个 CPU 内核在长/大文件传输期间的利用率达到约 70%（125GB 传输约需 45 秒）。但是，当两个 NIC 配置在一起时，每个 NIC 仅分配 2 个通道……因此，总共只有 4 个。但是，此时，CPU 内核（而不是 NIC）是瓶颈，分配的 4 个内核达到 100% CPU，从而将吞吐量限制在 35Gbps。（值得一提的是，两侧的 NVMe 存储都开始略微紧张……但就我目前注意到的情况而言，没有任何存储资源的利用率超过 60%）
我无法找到一种方法来覆盖连接的分配通道。我想将其设置为每个 NIC 4 个（服务器到服务器连接总共 8 个），但我似乎找不到支持覆盖该设置的任何命令。运行获取 SmbServer 配置和获取 SmbClient 配置都显示每个服务器的最大连接数设置为 32。运行获取 SmbMultichannelConnection | FL将显示单独的连接设置...但是，似乎没有互补的“Set-Smb ...”命令来更改这些值。
我确信这很简单，我只是忽略了一些显而易见的事情……但是，到目前为止，搜索互联网并没有找到任何线索。因此，任何帮助都将不胜感激。
答案1
好的...因此，我最初发布的问题的答案隐藏在 Windows 注册表设置中。
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\参数\ConnectionCountPerRdmaNetworkInterface
该键通常不存在于注册表中，如果未指定，则默认值为 2，但可以设置为 1 - 16。根据微软的这篇文章。
https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/file-server/
根据文章，这或多或少是一种“只可看不可摸”的设置。但奇怪的是，在同一地点有一个非常相似的设置……
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\参数\ConnectionCountPerRssNetworkInterface
它也建议不要更改。但尽管如此，他们还是通过 PowerShell 公开了它，可以通过以下方式查看和更改它：获取\设置 SmbClientConfiguration。为什么他们选择揭露其中一个，而不揭露另一个，这有点令人费解。
编辑+完整答案：
系统信息参考：
CPU：AMD EPYC 7313P 操作系统：Windows Server 2022 NIC：Intel E810-XXVDA2 驱动程序：Intel ProSet 27.6.1 流量测试：Windows 文件复制（传输 +100 个随机生成的 1GB 数据文件）- 具有讽刺意味的是，这具有最佳和最一致的结果。DiskSpd（借助 Microsoft 的 Test-Rdma.ps1）- 我调整了脚本输出以显示 kb、Mb、Gb 等，以使其更易于阅读。iPerf3 - 由于某种原因，设置变化无常，并且运行结果通常不一致。更正：
在原始帖子中，我提到了在启用第二个 SFP28 连接之前连接数为 4，但在启用第二个 SFP28 连接之后连接数为 2。嗯……事后看来，这有点不正确。允许 4 对 2 的原因是，当只有一个连接时，我还没有在 NIC 上启用 RDMA。如果没有 RMDA，SMB MultiChannel 将使用 RSS，并且有一个不同的设置……它很方便地具有默认值 4（请参阅我在发布的答案中提到的注册表项）。所以，就从 4 切换到 2 而言……这是我的错误。
最终解决方案：
在浏览了大量网站、多次关闭并重新创建连接后，我终于弄清楚了发生了什么。我最终通过更改其他 2 个设置（而不仅仅是我正在寻找的注册表项）解决了这个问题。
首先，该领域的许多大公司（微软、英特尔、nVidia、联想等）都建议禁用标准 RX/TX 流量控制。嗯……对于我的特定用例来说，这是一个糟糕的建议。重新启用流量控制有很大帮助。关闭标准流量控制的建议是改用基于优先级的流量控制 (PFC) 和数据中心桥接 (DCB)。但是……要使其正常工作，您的交换机还需要支持 PFC。虽然服务器之间的直接连接对此没有问题，但部署后位于它们之间的交换机不支持 DCB……所以，我想在不使用此功能的情况下继续。此外，使用 iWARP 时并不严格需要 PFC（它有助于提高性能……但不是成败攸关的要求）。所以，从我的测试来看，如果您不能使用带 DCB 的 PFC，您至少应该回退到使用标准 RX/TX 流量控制……这是我应该早点注意的事情。
另一个来自权威人士的建议是更改中断调节率或中断节流率 (ITR) 的设置。默认设置为“自适应”，但建议将其设置为禁用或关闭。更改此设置是一种平衡行为，在提高速度和降低延迟与响应更多来自 NIC 的中断请求导致的更高 CPU 使用率之间进行权衡。由于我的 CPU 遇到了瓶颈，我将设置从 OFF 更改为 LOW。
无论如何……这些是我必须更改的关键设置，以最终解决我的特定 CPU 固定问题。希望如果有人偶然发现这篇文章并遇到同样的问题，这将帮助他们更接近解决方案。