DOCA Bench

NVIDIA DOCA Bench 允许用户评估 DOCA 应用程序的性能，对于实际应用程序具有合理的准确性。它提供了一个灵活的架构，可以通过多核扩展串行评估多个功能，以提供详细的吞吐量和延迟分析。

此工具可用于评估多个 DOCA 操作的性能，深入了解复杂 DOCA 操作的每个阶段，并了解缓冲区大小调整、扩展和 GGA 配置等项目如何影响吞吐量和延迟。

DOCA Bench 被设计为所有 BlueField 加速器的统一测试工具。因此，它提供了以下主要功能

• BlueField 执行，利用 Arm 核心和 GGA “本地”

• 主机 (x86) 执行，利用 x86 核心和 BlueField 上通过 PCIe 的 GGA

• 支持以下 DOCA/DPU 功能

  • DOCA AES GCM

  • DOCA Comch

  • DOCA Compress

  • DOCA DMA

  • DOCA EC

  • DOCA Eth

  • DOCA RDMA

  • DOCA SHA

• 多核/多线程支持

• 基于时间、作业计数等安排执行

• 能够构建具有多个 GGA 的复杂管线（数据在管线中串行移动）

• 各种数据源（随机数据、文件数据、文件组等）

• 远程内存操作

  • 使用主机 x86 平台上的数据位置作为 GGA 的输入

• 全面的屏幕或 CSV 输出

• 查询功能，用于报告支持的软件和硬件功能

• 在起始值和结束值之间扫描参数，每次使用特定的增量

• 可以为每个 GGA 实例设置特定属性，从而可以精细控制 GGA 操作

• 作业批处理

DOCA Bench 安装在 DOCA-for-Host 和 DOCA BlueField Arm 包中均可用。它位于 /opt/mellanox/doca/tools 文件夹下。

先决条件

DOCA 2.7.0 及更高版本。

细粒度构建支持

DOCA Bench 支持细粒度构建环境，允许用户确定在任何目标系统上安装了哪些 DOCA 库。在初始化期间，DOCA Bench 会探测所有可用和支持的 DOCA 库，并提供测试这些库的能力。例如，如果 DOCA SHA 库不存在，则 DOCA Bench 不允许测试 SHA。

DOCA Bench 提供了一个查询系统，可以查询设备功能，以查看库是否确实已安装并受支持（在每个库的“installed : yes / no”部分下）。有关详细信息，请参阅“查询”部分。

DOCA Bench 测量吞吐量（带宽）或延迟的性能。

在此模式下，DOCA Bench 测量给定管线的最大性能（请参阅“核心原则”）。执行结束时，将显示简短摘要以及更详细的统计信息

            

            
Aggregate stats
        Duration:      3000049 micro seconds
        Enqueued jobs: 17135128
        Dequeued jobs: 17135128
        Throughput:    5712042 Operations/s
        Ingress rate:  063.832 Gib/s
        Egress rate:   063.832 Gib/s
        

延迟测量

延迟是执行特定操作所用时间的测量值。在此实例中，DOCA Bench 测量提交作业和接收响应之间所用的时间。

DOCA Bench 提供两种不同类型的延迟测量值

• 批量延迟模式 – 尝试并行提交一组作业以获得最大吞吐量，同时将延迟报告为组中提交的第一个作业和接收到的最后一个作业之间的时间。

• 精确延迟模式 – 用于确保在计划下一个作业之前仅提交和测量一个作业。

批量延迟

此延迟模式有效地以全速运行管线，尝试保持任何管线的最大吞吐量，同时还记录提交作业的延迟数据。

为了在以管线的最大吞吐量运行时记录延迟，用户必须将延迟数据放在组或“存储桶”中（而不是记录每个单独的作业延迟）。使用此方法，用户可以避免与每秒记录数百万个延迟数据相关的巨大内存和 CPU 开销（否则会显着降低性能）。

由于每个管线操作都不同，因此具有不同的延迟特性，用户可以提供延迟测量的边界。DOCA Bench 内部创建 100 个存储桶，用户可以指定起始值和每个存储桶的宽度或大小。第一个和最后一个存储桶具有重要意义

• 第一个存储桶包含所有执行速度快于起始周期的作业

• 最后一个存储桶包含执行时间超过允许的最大时间的作业计数

命令行选项 --latency-bucket-range 用于提供两个值，分别表示第一个存储桶的起始时间周期和每个连续存储桶的宽度。例如，--latency-bucket-range 10us,100us 将从测量 <10μs 响应时间的最低存储桶开始，然后是 100 个 100μs 宽的存储桶，以及一个用于结果超过 10010μs 的最终存储桶。

批量模式生成的报告通过两种方法可视化延迟数据

1. 提供条形图以直观地显示值在 --latency-bucket-range 选项指定的范围内的分布

   复制

   已复制！

               
   
               
   Latency report:
                      :
                      :
                      :
                      :
                      :
                      ::
                      ::
                      ::
                      ::
                     .::.  .    .    ..
   ------------------------------------------------------------------------------------------------------
           

2. 显示每个存储桶的作业数细分。此示例缩短了输出，以显示大多数值介于 27000ns 和 31000ns 之间。

   复制

   已复制！

               
   
               
   [25000ns -> 25999ns]: 0
   [26000ns -> 26999ns]: 0
   [27000ns -> 27999ns]: 128
   [28000ns -> 28999ns]: 2176
   [29000ns -> 29999ns]: 1152
   [30000ns -> 30999ns]: 128
   [31000ns -> 31999ns]: 0
   [32000ns -> 32999ns]: 0
   [33000ns -> 33999ns]: 128
   [34000ns -> 34999ns]: 0
   [35000ns -> 35999ns]: 0
           

精确延迟

此延迟模式一次对单个作业进行操作。以大大降低吞吐量为代价，这允许精确记录最小延迟。如下所示，生成的统计信息是精确的，并且包括各种字段，例如最小值、最大值、中值和百分位数。

            

            
Aggregate stats
 
        ....
        min:           1878 ns
        max:           4956 ns
        median:        2134 ns
        mean:          2145 ns
        90th %ile:     2243 ns
        95th %ile:     2285 ns
        99th %ile:     2465 ns
        99.9th %ile:   3193 ns
        99.99th %ile:  4487 ns
        

以下小节详细阐述了理解 DOCA Bench 运行方式至关重要的原则。

主机或 BlueField Arm 执行

无论是在 x86 主机还是 BlueField Arm 上执行 DOCA Bench，DOCA Bench 的行为都是相同的。测量的性能取决于环境。

管线

DOCA Bench 是一种高度灵活的工具，能够配置操作的发生方式和顺序以及操作内容。为了实现此目的，DOCA Bench 使用操作管线，这些操作称为“步骤”。这些步骤可以是特定的功能（例如，以太网接收、SHA 哈希生成、数据压缩）。因此，步骤管线可以完成多个顺序操作。DOCA Bench 可以测量这些管线的吞吐量性能或延迟，无论是在单核还是多核/多线程上运行。

预热期

为了确保正确的测量，管线必须“热”运行（即，在实际性能测量开始之前，必须运行任何初始内存、缓存和硬件子系统）。这被称为“预热”期，默认情况下，在开始测量之前，大约有 250 个作业通过管线运行。

默认值

DOCA Bench 有大量参数，但为了简化执行，只需提供少量参数即可开始性能测量。因此，各种参数都有默认值，这些默认值对于大多数情况都应该足够。为了微调性能，用户应密切关注可能影响其管线操作的任何默认参数。

优化性能

为了获得最佳性能，任何给定环境都需要进行一定量的调整。虽然这超出了本文档的范围，但建议用户

• 避免使用 CPU 0，因为大多数操作系统进程和中断请求 (IRQ) 处理程序都计划在此核心上执行

• 在内核引导参数中启用 CPU/IRQ 隔离，以从他们希望在其上执行性能测试的任何核心中移除内核活动

• 在主机上，确保在寻址 BlueField 时不要跨越任何非统一内存访问 (NUMA) 区域

• 了解场景的内存分配要求，以避免过度分配或陷入接近内存不足的情况

DOCA Bench 可以在主机和 BlueField Arm 环境中执行，并且可以面向 BlueField 网络平台。

下表显示了使用 DOCA Bench 可以执行哪些操作。它还提供了两列，显示远程内存是否可以用作该操作的输入或输出。例如，BlueField Arm 上的 DMA 操作可以访问远程内存作为输入，以将内存从主机拉入 BlueField Arm）。

1. lz4 解压缩不支持输入远程内存     

BlueField 操作的子集具有远程元素，无论是 RDMA 连接、以太网连接还是驻留在 x86 主机上的内存。所有这些操作都需要远端存在代理，以方便对该特定功能进行基准测试。

在 DOCA Bench 中，此代理是一个额外的独立应用程序，称为“伴侣应用程序”。它提供远程基准测试设施，并且是标准 DOCA Bench 安装的一部分。

下图概述了 DOCA Bench 和伴侣应用程序之间的功能和通信

在此特定设置中，BlueField 执行“DOCA Bench”，而主机 (x86) 执行伴侣应用程序。

DOCA Bench 还充当测试的控制器，指示伴侣应用程序根据需要执行必要的操作。两个应用程序之间存在带外通信通道，该通道利用标准 TCP/IP 套接字或 DOCA Comch 通道（取决于测试场景/用户偏好）。

扩展任何应用程序的关键要求是分配给任何给定活动的 CPU 核心或线程数。DOCA Bench 提供了指定核心数以及每个核心要创建的线程数的能力，以最大限度地增加提交到给定管线的作业数。

选择 CPU 或线程数时应注意以下事项

• 位于远处 NUMA 区域（即，与 BlueField 连接的 NUMA 区域不同）上的核心上的线程将体验到较低的性能和较高的延迟

• 核心 0 通常是操作系统最常用的核心，应避免使用

• 标准 Linux 内核安装允许操作系统在任何 CPU 核心上移动进程，从而由于进程切换而导致性能意外下降或延迟升高

CPU 核心的选择通过 --core-mask、--core-list、--core-count 参数提供，而线程的选择通过 --threads-per-core 参数进行。

从主机 (x86) 环境执行时，DOCA Bench 可以面向已安装环境中的一个或多个 BlueField 设备。从 BlueField Arm 执行时，目标始终是本地 BlueField。

从主机或 BlueField Arm 定位给定 BlueField 的默认方法是使用 --device 或 -A 参数，可以提供为

• 设备 PCIe 地址（即，03:00.0）；

• 设备 IB 名称 (mlx5_0)；或

• 设备接口名称 (ens4f0)

从 BlueField Arm 环境，DOCA Bench 应面向本地 PCIe 地址（即，--device 03:00.0）或 IB 设备名称（即，mlx5_0）。

DOCA Bench 支持不同的方法来向作业提供数据并提供有关每个作业要处理的数据量的信息。这些被称为“数据提供程序”。

输入数据选择

以下小节提供了可用于为任何操作提供输入数据的模式。

文件

单个文件用作操作的输入。文件的内容对于某些操作（例如，DMA、SHA 等）并不重要，但对于其他操作（例如，解压缩等）必须有效且特定。如果操作需要的数据多于单个文件包含的数据，则可以多次使用和重复数据。有关如何在复杂操作中处理文件数据的更多信息，请参阅“命令行参数”部分。

文件集

文件集是一组文件，主要用于结构化数据。文件集中的数据实际上是文件列表，以换行符分隔，依次用作作业的输入数据。文件集中指向的每个文件都会将其全部内容读取到单个缓冲区中。这对于需要结构化数据的操作很有用（即，完整有效的数据块，例如解压缩或 AES）。

随机数据

当给定操作所需的实际数据不特定时（例如，DMA），则提供随机数据。

作业大小调整

DOCA Bench 中的每个作业都包含三个缓冲区：原始输入缓冲区、输出缓冲区和中间缓冲区。

输入缓冲区由数据提供程序提供，供管线中的第一步使用，之后，后续步骤以乒乓方式使用输出和中间缓冲区（可以使用 --job-output-buffer-size 调整大小）。这意味着，管线始终可以从相同的确定性数据开始，同时允许每个步骤提供其新生成的输出数据，以用作下一步的输入。

输入缓冲区通过两种方式之一指定：使用 uniform-job-size 使每个输入缓冲区的大小完全相同，或使用文件集根据所选输入数据文件的大小调整每个缓冲区的大小。用户应确保管线中每个步骤生成的数据将适合提供的输出缓冲区。

DOCA Bench 有多种方法可以控制执行测试的长度 - 无论是基于数据还是时间限制。

限制为特定秒数

使用 --run-limit-seconds 或 -s 参数可确保执行持续特定秒数。

限制为作业总数

可能需要测量通过管线的特定作业数。--run-limit-jobs 或 -J 参数用于指定提交到管线并允许完成的确切作业数，然后执行完成。

由于 DOCA Bench 支持各种基于 GGA 和软件的 DOCA 库，因此微调其调用能力非常重要。命令行参数通常用于适用于 DOCA Bench 所有方面的配置选项，而无需特定于特定的 DOCA 库。

属性是向特定 DOCA 库提供配置选项的方法，虽然存在一些共享属性，但大多数库都具有旨在控制其特定行为的特定属性。

例如，属性 doca_ec.data_block_count 允许您为 DOCA EC 库设置数据块计数，而属性 doca_sha.algorithm 控制 SHA 算法的选择。

有关支持属性的完整列表，请参阅“命令行参数”部分。

DOCA Bench 允许用户指定要执行的一系列操作，然后在多个 CPU 核心/线程上扩展该工作负载，以估计该工作负载的性能以及深入了解哪些阶段（如果有）导致其性能问题。然后，用户可以修改各种配置属性，以探索如何调整问题以更好地满足其需求。

运行时，DOCA Bench 创建多个执行线程，这些线程与用户指定的特定 CPU 具有亲和性。每个线程都为自己唯一创建作业池（作业数据由数据提供程序初始化）和工作负载步骤管线。

CPU 核心和线程计数配置

执行性能测试时涉及许多因素，其中之一是 CPU 选择

• 用户在选择要使用的核心时应考虑 NUMA 区域，因为使用远离被测设备的核心可能会影响可实现的性能

• 用户可能还希望避免使用核心 0，因为这通常是内核中断处理程序的默认核心。

--core-mask

默认值： 0x02

核心掩码是指定要使用的核心的最简单方法，但它受到限制，因为它只能指定最多 32 个 CPU (0-31)。用法示例：--core-mask 0xF001 选择 CPU 核心 0、12、13、14 和 15。

--core-list

核心列表可以将给定系统中的任何/所有 CPU 核心指定为列表、范围或两者的组合。用法示例：--core-list 0,3,6-10 选择 CPU 核心 0、3、6、7、8、9 和 10。

--core-count

如果需要，用户可以从给定的核心集（列表或掩码）中选择前 N 个核心。用法示例：--core-count N。

--threads-per-core -t

为了测试单个 CPU 核心内的争用影响，用户可以指定此值，以便不是每个核心仅创建一个线程，而是创建 N 个线程，并且其亲和性掩码设置为每个选定核心的给定核心。例如，3 个核心和每个核心 2 个线程总共创建 6 个线程。

设备配置

测试需要使用至少一个 BlueField 才能执行。对于远程系统测试，可能需要第二个设备。

--device -A

从被测系统的角度指定要使用的设备。该值可以是设备 PCIe 地址（例如，03:00.0）、设备 IB 设备名称（例如，mlx5_0）或设备接口名称（例如，ens4f0）中的任何一个。

--representor -R

仅当在使用 DOCA Comch 在 BlueField 设备及其主机之间执行远程内存操作时，才使用此选项。这通常由伴侣连接字符串自动完成，但存在一些开发人员调试用例。

输入数据和缓冲区大小配置

DOCA Bench 支持多种获取数据的方法，用于初始化作业缓冲区。用户还可以配置与每个作业关联的输出/中间缓冲区。

--data-provider -I

DOCA Bench 支持几种不同的输入数据源

• 文件

• 文件集

• 随机数据

文件数据提供程序

文件数据提供程序通过使用单个输入文件来生成统一/非结构化数据缓冲区。输入数据被剥离和/或重复以根据需要填充每个数据缓冲区，每次耗尽时返回到文件开头以收集更多数据。当被测组件的性能旨在显示取决于提供的输入数据的不同性能特征时，这是理想的。

例如，无论输入数据如何，doca_dma 和 doca_sha 都将在恒定时间内执行。而 doca_compress 对于具有更多重复数据的数据会更快，而对于真正的随机数据会更慢，并且会根据输入数据产生不同的输出。

示例 1 – 具有大缓冲区的小输入文件

给定一个小输入数据（即，小于数据缓冲区大小），文件内容会重复，直到缓冲区被填满，然后继续到下一个缓冲区。因此，如果输入文件包含数据 012345 并且用户请求了两个 20 字节的缓冲区，则缓冲区将如下所示

• 01234501234501234501

• 23450123450123450123

示例 2 – 具有较小缓冲区的大输入文件

给定一个大输入数据（即，大于数据缓冲区大小），文件内容将分布在数据缓冲区中。如果输入文件包含数据 0123456789abcdef 并且用户请求了三个 12 字节的缓冲区，则缓冲区将如下所示

• 0123456789ab

• cdef01234567

• 89abcdef0123

文件集数据提供程序

文件集数据提供程序生成结构化数据。文件集输入文件本身是一个包含一个或多个文件名的文件（相对于输入 "命令工作目录 (cwd)"，而不是相对于文件集文件）。文件集中列出的每个文件都会将其全部内容用作作业缓冲区。这对于数据必须是完整有效的数据块才能使操作成功的情况很有用，例如使用 doca_compress 进行解压缩或使用 doca_aes 进行解密。

示例 – 文件集及其内容

给定 "命令工作目录 (cwd)" 中的文件集，该文件集引用 data_1.bin 和 data_2.bin（每行一个文件名），并且 data_1.bin 包含 33 个字节，data_2.bin 包含 69 个字节，然后缓冲区所需的数据将以循环方式填充这两个文件，直到缓冲区满为止。与统一（非结构化）数据不同，每个任务可以具有不同的长度。

随机数据数据提供程序

随机数据数据提供程序从随机数据源提供统一（非结构化）数据。每个缓冲区都将具有唯一的（伪）随机字节内容。

--data-provider-job-count

默认值 128

DOCA Bench 中的每个线程都有自己的作业数据缓冲区分配，以避免内存争用问题。用户可以使用此参数选择每个线程应创建多少个作业。

--data-provider-input-file

对于使用输入文件的数据提供程序，可以在此处指定文件名。文件名相对于 input_cwd。

--uniform-job-size

指定应创建的统一输入缓冲区的大小（以字节为单位）。

--job-output-buffer-size

默认值 16384

指定输出/中间缓冲区的大小（以字节为单位）。每个作业有 3 个缓冲区：不可变的输入缓冲区和两个输出/中间缓冲区。这允许管线在整个管线中无限次地更改数据，同时允许在末尾重置和重复使用数据，并允许任何步骤使用前一步创建的新更改的数据。

--input-cwd -i

为了简化配置管理，用户可以选择为给定场景的输入数据使用单独的文件夹，而不是 DOCA 构建/安装目录。

示例 1 – 从当前工作目录运行 DOCA Bench

考虑到用户从 /home/bob/doca/build 执行 DOCA Bench，在 --data-provider-input-file 中指定的值和文件集中的文件名将相对于 shell 的“命令工作目录 (cwd)”搜索：/home/bob/doca/build。他们的命令可能看起来像这样

            

            
doca_bench --data-provider file-set --data-provider-input-file my_file_set.txt 
        

并假设 my_file_set.txt 包含 data_1.bin，则 DOCA Bench 在路径解析后加载的文件将是

• /home/bob/doca/build/my_file_set.txt

• /home/bob/doca/build/data_1.bin

示例 2 – 从另一个目录运行 DOCA Bench

考虑到用户从上一级目录执行相同的测试。类似这样的

            

            
build/doca_bench --data-provider file-set --data-provider-input-file build/my_file_set.txt
        

要加载的文件将是

• /home/bob/doca/build/my_file_set.txt

• /home/bob/doca/data_1.bin

请注意，这两个文件都是相对于 "命令工作目录 (cwd)" 加载的，并且数据文件不是相对于文件集加载的。

示例 3 – 使用 input-cwd 重新访问示例 2

用户可以通过将所有输入文件保存在单个目录中，然后使用参数 input-cwd 引用该目录来轻松解决此问题。在这种情况下，类似这样的命令行可能看起来像

            

            
build/doca_bench --data-provider file-set --data-provider-input-file my_file_set.txt --input-cwd build
        

请注意，--data-provider-input-file 的值也已更改为相对于新的 "命令工作目录 (cwd)"。

这次加载的文件又回到了预期的状态

• /home/bob/doca/build/my_file_set.txt

• /home/bob/doca/build/data_1.bin

测试执行控制

DOCA Bench 支持多种测试模式和运行执行限制，以允许用户配置测试类型和持续时间。

--mode

默认值： 吞吐量

选择要执行的测试类型。

吞吐量模式

吞吐量模式经过优化，可在给定时间内增加处理的数据量，而几乎不考虑延迟影响。吞吐量模式尝试使每个被测组件尽可能忙碌。带宽和作业执行速率的摘要作为输出提供。

批量延迟模式

批量延迟模式在吞吐量和延迟之间取得平衡，提交一批作业并等待它们全部完成，以测量每个作业的延迟。此模式使用分桶机制，使 DOCA Bench 能够处理数百万个作业的结果。DOCA Bench 记录在每个桶内完成的作业数量，使其能够长时间运行。输出结果会提供结果分布的摘要以及结果的 ASCII 直方图。报告的延迟是从首次提交作业（针对一批作业）到收到最终作业响应（针对同一批作业）之间所花费的时间。

精确延迟模式

精确延迟模式一次执行一个作业，以便 DOCA Bench 计算作业的最小可能延迟。这会导致能够并行处理许多作业的组件利用率严重不足，从而大大降低带宽。由于此模式单独记录每个结果，因此不应将其用于执行超过数千个作业。精确延迟模式每个结果需要 8 字节的存储空间，因此请注意要执行的作业数量带来的内存开销。

输出结果会提供统计分析，包括延迟值的最小值、最大值、平均值、中位数和一些百分位数。

--latency-bucket-range

默认值： 100 毫秒, 10 毫秒

仅适用于批量延迟模式。允许用户指定桶的起始值和每个桶的宽度。共有 100 个给定大小的桶，以及用于存放超出中心范围结果的下溢桶和溢出桶。

例如

            

            
--latency-bucket-range 10us,100us
        

这将从测量 <10μs 响应时间的最低桶开始，然后是 100 个宽度为 100μs 的桶，以及一个用于存放响应时间超过 >10010μs 的结果的最终桶。

阻塞模式

DOCA 支持两种等待任务完成的方法

• 忙等待（或轮询）模式

• 通知驱动模式

  信息

  有关更多信息，请参阅“DOCA SDK 架构”文档。

默认情况下，DOCA Bench 使用忙等待来确保任何给定管道及其任务的最大带宽（和低延迟），并充分利用任何已分配的 CPU 资源。

与所有高性能软件一样，利用 GGA 或硬件加速器，在较小的数据包大小下（即，在较小的负载大小下，CPU 花费大量时间生成任务和处理完成），性能通常受 CPU 限制。对于较大的数据包大小，CPU 提交的任务较少，因为每个任务包含更多数据，因此它可能很容易提交比 GGA 或硬件加速器可以接受的更多数据，从而导致 CPU 忙于等待完成才能提交更多任务的情况。

--use-blocking-mode

此选项使 DOCA Bench 使用“通知驱动模式”方法来等待任务完成。

--record-cpu-usage

如果指定，此选项会报告 DOCA Bench 正在其上运行的任何 CPU 核心的 CPU 统计信息。如果“通知驱动”模式处于活动状态，这将提供关于返回多少 CPU 时间以及因此可用于其他进程或线程的指导。

提供的统计信息包括 CPU 使用率的最小值、最大值、中位数和平均值。还包括一些百分位数结果，显示第 90、第 95 和多个第 99 百分位数的值。输出示例

            

            
CPU Usage stats
        min:           25%
        max:           50%
        median:        50%
        mean:          45.8333%
        90th %ile:     50%
        95th %ile:     50%
        99th %ile:     50%
        99.9th %ile:   50%
        99.99th %ile:  50%
        

执行限制

默认情况下，测试会永远运行。这通常是不希望看到的，因此用户可以为测试指定一个限制。

--run-limit-seconds -s

按照用户指定的 N 秒运行测试。

--run-limit-jobs -J

运行测试，直到至少提交了 N 个作业，然后允许正在进行的作业完成，然后再退出。根据批处理大小，可能会执行超过 N 个作业。

--run-limit-bytes -b

运行测试，直到至少提交了 N 字节的数据，然后允许正在进行的作业完成，然后再退出。如果限制不是作业输入缓冲区大小的倍数，则可能会处理比预期更多的数据。

批处理支持

DOCA Bench 支持批量提交作业以提高性能。

--batch-mode

默认值： 无

指定要使用的批处理模式。以下选项可用

• --batch-mode none – 无批处理，每次提交作业后按门铃

• --batch-mode batch-submit – 提交一批作业，然后按门铃。要提交的作业数由 --batch-size 参数指定。如果要提交的作业数少于 batch-size，则在提交最后一个作业后按门铃。

• batch-submit-minimal-reports – 提交一批作业并按门铃，但将作业的完成回调延迟到稍后的时间。通过接收整个批次的单个完成通知，减少在提交一批作业后收到的完成通知数量。

--batch-size

默认值 1

指定在按门铃之前每个批次中要包含的作业数。

收集/分散支持

Gather 支持涉及将来自单个缓冲区的传入输入数据分解为多个缓冲区，这些缓冲区“收集”到一个gather列表中。目前仅支持gather。

--gather-value

默认值 1

指定将来自单个缓冲区的输入数据分区到gather列表。该值可以以两种形式指定

• --gather-value 4 – 将输入缓冲区尽可能均匀地拆分为 4 部分，奇数字节在最后一段

• --gather-value 4KiB – 每 4KB 数据后拆分缓冲区。有关可能的单位列表，请参阅 doca_bench/utility/byte_unit.hpp。

统计输出

--rt-stats-interval

默认情况下，DOCA Bench 在迭代完成后发出迭代结果。用户可以通过提供 --rt-stats-interval 参数（值为表示统计信息打印之间毫秒数的数值）来请求在测试进行过程中统计信息的瞬时快照。运行的最终结果仍然会正常显示。

--csv-output-file

DOCA Bench 可以在执行过程中生成一个输出文件，其中可以包含统计信息和用于生成该统计信息的配置值。通过指定 --csv-output-file 参数并将文件路径作为值来启用此功能。为此参数提供值将启用 CSV 统计信息输出（除了正常的控制台输出之外）。执行扫描测试时，扫描测试的每次迭代填充一行。

默认情况下，CSV 输出包含每个可能的值。用户可以通过应用过滤器来调整此设置。

--csv-stats

提供一个或多个过滤器（正向或负向）以调整要显示的统计信息。此参数的值是以逗号分隔的过滤器字符串列表。负向过滤器以减号 ('-') 开头。

示例 1 – 仅发出统计值（无配置值）

            

            
 --csv-stats "stats.*"
        

示例 2 – 发出统计值和一些配置值（删除属性值）

            

            
--csv-stats "stats.*,-attribute* 
        

--csv-append-mode

默认值： false

启用后，如果 CSV 文件存在，DOCA Bench 会追加到该文件，如果不存在，则创建一个新文件。假定所有调用都使用完全相同的输出值集。DOCA Bench 不会验证这一点。用户必须确保所有追加到 CSV 的测试都使用相同的输出值集。

--csv-separate-dynamic-values

一种特殊情况，它会创建一个非标准的 CSV 文件。首先仅报告扫描测试不支持的所有值，然后为测试期间发出的值添加新的标题行，然后为每个测试结果添加一行。这仅供内部使用，不应被其他人依赖。

--enable-environment-information

指示 DOCA Bench 收集一些详细的系统信息作为测试启动过程的一部分，这些信息随后可在 CSV 中输出。如果使用了 companion，这些信息还会从 companion 端收集相同的详细信息。

远程内存测试

某些库（例如 doca_dma）支持使用远程内存。要启用此功能，用户可以指定远程内存标志 --use-remote-input-buffers 和 --use-remote-output-buffers 中的一个或两个。这告诉 DOCA Bench 使用 companion 创建远程 mmap。然后，此远程 mmap 用于创建提交到被测组件的缓冲区。

--use-remote-input-buffers

指定用于管道中初始不可变作业输入缓冲区的内存应由远程端的 mmap 支持。

--use-remote-output-buffers

指定正在使用的所有输出缓冲区和转换缓冲区都由远程端的 mmap 支持。

--mtu-size

用于 doca_rdma。值是一个枚举：256B、512B、1KB、2KB、4KB 或 raw_eth。

--receive-queue-size

用于 doca_rdma。独立于 SQ 大小配置 RDMA RQ 大小。

--send-queue-size

用于 doca_rdma。独立于 RQ 大小配置 RDMA SQ 大小。

DOCA Lib 配置选项

--task-pool-size

默认值 1024

配置库初始化任务池时使用的最大任务池大小。

管线配置

DOCA Bench 基于操作管道，这允许在复杂的测试场景中并行测试多个组件。目前仅支持管道中的单个操作链（但在多个核心或线程之间扩展），未来的版本将允许每个 CPU 核心使用不同的管道。

管道被描述为一系列步骤。所有步骤都有一些一般特征

• 步骤类型：doca_dma、doca_sha、doca_compress 等。

• 操作类别 – 转换型或非转换型

• 输入数据类别 – 结构化或非结构化

单个步骤类型也可能具有一些额外的元数据信息或配置，这些信息或配置是根据每个步骤定义的。

元数据示例

• doca_compress 需要操作类型：compress 或 decompress

• doca_aes 需要操作类型：encrypt 或 decrypt

• doca_ec 需要操作类型：create、recover 或 update

• doca_rdma 需要方向：send、receive 或 bidir

配置示例

• --pipeline-steps doca_dma

• --pipeline-steps doca_compress::compress,doca_compress::decompress

--pipeline-steps

定义要由测试的每个线程执行的步骤（逗号分隔列表）。

以下是支持的步骤列表

• doca_compress::compress

• doca_compress::decompress

• doca_dma

• doca_ec::create

• doca_ec::recover

• doca_ec::update

• doca_sha

• doca_rdma::send

• doca_rdma::receive

• doca_rdma::bidir

• doca_aes_gcm::encrypt

• doca_aes_gcm::decrypt

• doca_cc::client_producer

• doca_cc::client_consumer

• doca_eth::rx

• doca_eth::tx

--attribute

某些选项非常小众或特定于单个步骤/mmo 类型，因此它们被简单地定义为属性，而不是唯一的命令行参数。

以下是支持的选项列表

• doption.mmp.log_qp_depth

• doption.mmo.log.num_qps

• doption.companion_app.path

• doca_compress.algorithm

• doca_ec.matrix_count

• doca_ec.data_block_count

• doca_ec.redundancy_block_count

• doca_sha.algorithm

• doca_rdma.gid-index

• doca_eth.max_burst_size

• doca_eth.l3_chksum_offload

• doca_eth.l4_chksum_offload

--warm-up-jobs

默认值 100

预热有两个目的

• 首先，它以循环方式运行 N 个任务，以在测试开始测量之前将数据路径代码、任务内存和任务数据缓冲区内存加载到 CPU 缓存中。

• 其次，它使用 doca_task_try_submit 而不是 doca_task_submit 来验证作业。在正确的“热路径”期间，这种验证是不希望看到的，因为它会花费时间在每次执行时重新验证任务。

用户应确保其预热计数等于或超过每个线程使用的任务数（请参阅 --data-provider-job-count）。

伴侣配置

某些测试需要远程系统才能运行。为此，DOCA Bench 捆绑了一个 companion 应用程序（此应用程序作为 DOCA-for-Host 或 BlueField 软件包的一部分安装）。companion 负责为 DOCA Bench 提供服务，例如在远程端创建 doca_mmap 并将其导出以用于远程操作，如 doca_dma/doca_sha，或其他支持远程内存输入缓冲区的 doca_libs。DOCA Bench 还可以为需要远程工作进程的库（如 doca_rdma 和 doca_cc）提供远程工作进程。通过提供 --companion-connection-string 参数来启用 companion。通过提供 --companion-core-list 或 --companion-core-mask 参数中的任一个来启用 Companion 远程工作进程。

companion 连接还可以指定 no-launch 选项。

用户还可以指定特定 companion 二进制文件的路径，以允许他们使用以下命令测试不在默认安装路径中的 companion 二进制文件

            

            
--attribute doption.companion_app.path=/tmp/my_doca_build/tools/bench/doca_bench_companion
        

--companion-connection-string

指定建立与 companion 进程的连接并执行该进程所需的详细信息。

• 从主机端运行 DOCA Bench，使用 BlueField 作为远程端，并使用 doca_comch 作为通信方法的示例

  复制

  已复制！

              
  
              
  --companion-connection-string "proto=dcc,mode=DPU,user=bob,addr=172.17.0.1,dev=03:00.0,rep=d8:00.0"
          

• 从 BlueField 端运行 DOCA Bench，使用主机作为远程端，并使用 doca_comch 作为通信方法的示例

  复制

  已复制！

              
  
              
  --companion-connection-string "proto=dcc,mode=host,user=bob,addr=172.17.0.1,dev=d8:00.0"
          

• 在一台主机上运行 DOCA Bench，在另一台主机上运行 companion，并使用 TCP 作为通信方法的示例

  复制

  已复制！

              
  
              
  --companion-connection-string "proto=tcp,user=bob,addr=172.17.0.1,port=12345,dev=d8:00.0"
          

  注意

  仅适用于 doca_rdma。

--companion-core-list

工作方式与 --core-list 相同，但定义了要在 companion 端使用的核心。

--companion-core-mask

工作方式与 --core-mask 相同，但定义了要在 companion 端使用的核心。

扫描测试

--sweep

DOCA Bench 支持基于多个值范围执行一组测试。例如，为了了解多线程的性能，用户可能希望针对各种 CPU 核心计数运行相同的测试。他们可能还希望更改测试的多个方面。提供一个或多个 --sweep 参数会激活扫描测试模式，其中每个值组合都通过 DOCA Bench 的单次调用进行测试。

以下是支持的扫描测试选项列表

• core-count

• data-provider-input-file

• data-provider-job-count

• gather-value

• mtu-size

• receive-queue-size

• send-queue-size

• threads-per-core

• task-pool-size

• uniform-job-size

• doption.mmo.log_qp_depth

• doption.mmo.log_num_qps

• doca_rdma.transport-type

• doca_rdma.gid-index

扫描测试参数值采用以下三种形式之一

• --sweep param,start_value,end_value,+N

• --sweep param,start_value,end_value,*N

• --sweep param,value1,...,valueN

扫描核心计数和输入文件示例

            

            
--sweep core-count,1,8,*2 –sweep data-provider-input-file,file1.bin,file2.bin 
        

这将扫描核心 1-8（包括 8），每次都将值乘以 1、2、4、8，并使用两个不同的输入文件，从而产生累积的 8 个测试用例

查询

设备功能

DOCA Bench 允许查询设备以报告哪些步骤类型可用，以及每个步骤的有效配置选项的信息。必须指定设备

            

            
tools/bench/doca_bench --device 03:00.0 --query device-capabilities
        

对于每个受支持的库，这将报告

• 功能 – 如果该库在编译时在 DOCA Bench 中启用（如果功能不足，安装该库不会使其可用于基准测试）

• 已安装 – 如果该库安装在执行查询的计算机上（如果未安装，安装它将使其可用于基准测试）

• 库范围属性

• 受支持的任务类型列表（~= 步骤名称）

  • 如果支持任务类型

  • 任务特定属性/功能

            

            
doca_compress:
	Capable: yes
	Installed: yes
	Tasks: 
		compress::deflate: 
			Supported: no
		compress::lz4: 
			Supported: no
		compress::lz4_stream: 
			Supported: no
		decompress::deflate: 
			Supported: yes
			Max buffer length: 134217728
		decompress::lz4: 
			Supported: yes
			Max buffer length: 134217728
		decompress::lz4_stream: 
			Supported: yes
			Max buffer length: 134217728  
        

支持的扫描属性

显示可与扫描测试参数一起使用的可能参数

            

            
tools/bench/doca_bench --query sweep-properties
        

输出示例

            

            
Supported query properties: [
        core-count
        threads-per-core
        uniform-job-size
        task-pool-size
        data-provider-job-count
        gather-value
        mtu-size
        send-queue-size
        receive-queue-size
        doption.mmo.log_qp_depth
        doption.mmo.log_num_qps
        doca_rdma.transport-type
        doca_rdma.gid-index
]
        

DOCA Bench 根据输入缓冲区大小、输出/中间缓冲区大小、核心数、线程数和正在使用的作业数，为测试所需的所有任务分配内存。所有作业都包含一个输入缓冲区、一个输出缓冲区和一个中间缓冲区。输入缓冲区是不可变的，其大小基于正在使用的数据提供程序。输出缓冲区和中间缓冲区的大小基于用户规范或根据用户请求自动计算。对于生成与其消耗量相同输出量的库（例如 doca_dma），通常用户应将所有缓冲区设置为相同大小，以尽可能提高效率。

作业缓冲区的内存占用量可以计算为：(任务数) * (核心数) * (每个核心的线程数) * (输入缓冲区大小 + (输出/中间缓冲区大小 * 2))。对于 1KB 作业，默认设置为 32 个作业、1 个核心和每个线程 1 个核心，则内存占用量为 96KB。

对于扫描测试和结构化数据输入，可能很难选择合适的输出缓冲区大小，因此用户可以选择指定 0，并让 DOCA Bench 尝试所有任务一次，以计算所需的输出缓冲区大小。这仅在执行计算所花费的时间方面有成本。在此之后，自动调整大小和手动调整作业输出缓冲区大小之间没有区别。