[参考译文] AM6442：Linux 上的 PRP 吞吐量

您好、Daolin

感谢您的快速响应。
请继续讨论这一问题一段时间。
我想再问几个问题。

[报价 userid="576780" url="~/support/processors-group/processors/f/processors-forum/1404677/am6422-prp-throughput-on-linux/5377774 #5377774"]

对此有几个初步建议：

• 提升 ksoftirq 线程的优先级
• 将 ksoftirq 的调度策略从"TS"更改为"FIFO"并提升优先级
• 提升 iperf3的优先级(如果这是您用于测试 PRP 吞吐量的测试程序)

[报价]

我使用 iperf3。
Linux 启动后运行的唯一进程或内核处理是 iperf3和 PRP 通信。
在启动 iperf3之前、A53负载仅为2-3%、但在 iperf3运行时、它会达到约90%的极限。
您建议的方法优先于 iperf3和相关流程、而不是其他流程、
因此、我认为如果几乎没有其他流程、它将不会非常有效。
提高 PRP 吞吐量的一种方法是进行 PRP 并行处理、以便能够充分利用 AM6442上的两个 A53内核。
这是可行的吗？
不使用 PRP 时、iperf3吞吐量为800Mbps、但此时的 CPU 负载达到约90%的极限。

Unknown 说：

您是否正在使用 https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_02_01_09/exports/docs/linux/Network/HSR_PRP_C.html 中提供的设置步骤 Kernel_Drivers ？Foundational_Components Non_Offload 根据同一页、支持 IEC 62439-3。[/QUOT]

是的、它的过程与您提供给我的信息几乎相同。 区别在于我使用了"ifconfig"来设置"IP link"。
我们使用它的方式似乎没有问题、因此我们可以假设 PRP 吞吐量仅为300Mbps 的问题是 AM6442的限制吗？
您的环境中是否获得了类似的结果？
是否有任何计划提高 PRP 非卸载实施的吞吐量？

Unknown 说：

您可能已经知道、最新发布的 SDK 10.00.07.04 (2024年8月14日)不支持卸载 PRP。 如 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1397884/am6442-prp-offload-firmware-on-linux 中所述、通过卸载 PRP 可以找到有限的改进。 PRP 卸载支持目前计划于2025年1小时提供。

感谢您提供有关何时支持 PRP 卸载的信息。
发送方上的 dup-offload 和 tag-in-offload 以及接收器上的 tag-rm-offload 几乎可以完全覆盖 PRP 处理、
因此、卸载的影响可能会很大。
如果使用 PRP 卸载功能、即使 PRP 吞吐量未提高到300Mbps、
希望 A53内核上的负载会降至未使用 PRP 时的负载水平。

提前感谢您
此致、
大野武志

[/quote]

您好、Takeshi

Unknown 说：

Linux 启动后运行的唯一进程或内核处理是 iperf3和 PRP 通信。

您应该能够看到 ksoftirq 线程、其中包含"ps -alo psr、policy、priority、pid、tid、cputime、comm | grep ksoft"。 这些线程与处理以太网中断相关、因此我们建议尝试提升优先级、并将调度策略更改为更方便实时的调度策略。

Unknown 说：

提高 PRP 吞吐量的一种方法是进行 PRP 并行处理、以便能够充分利用 AM6442上的两个 A53内核。
这是可行的吗？

根据我的理解、一个进程只能同时使用多个内核、前提是它已经过编程/设计、以便可以拆分为 多个可并行化的线程、每个线程都可以在不同的内核上运行。 PRP 设置似乎并不是一个应用级程序、而是似乎是通过 Linux 驱动程序进行配置、因此我认为不可能实现 PRP 的并行处理。 但是、我的陈述可能不正确、我会再次与内部团队核实。

Unknown 说：

PRP 处理几乎可以完全由发件人上的 dup-offload 和 tag-in-offload 所覆盖、接收器上的 tag-rm-offload 所覆盖、
因此、卸载的影响可能是 grea[/报价]

我们目前没有关于特定 CPU 负载改进(特别是 dup-offload、tag-in-offload 和 tag-rm-offload)的数据、但效果应该存在、但不会像在 HSR 设置中看到的转发卸载那样好。

  通过仅使用 dup-offload、tag-in-offload 和 tag-rm-offload 测试 HSR、 而不使用 dup-offload、tag-in-rm 和 tag-offload、tag-in-rm 和 tag-offload 来估算 CPU 负载改善情况、可能是一种衡量 dup-offload、tag-in-offload 和 tag-rm 卸载的潜在方法。

Unknown 说：

您的环境中是否获得了类似结果？
是否有任何计划提高 PRP 非卸载实施的吞吐量？

我最近还不能在我的环境中测试 PRP、但我会在周五或下周早些时候进行测试。 如果我能够复制您看到的性能、我还需要与开发团队核实是否有任何改进 PRP 非卸载实施的计划。 据我所知、这并不是因为我们计划支持 PRP 卸载。

如果下周一之前没有收到我的回复、请随时再次 ping 通该主题。

-道林

[/quote]

您好、Takeshi

您选择 AM64x 而不是 AM62x 的原因是否特殊？ AM62x 价格更低、无需软件即可实现更高的吞吐量(与 AM64x 2 A53内核相比、具有4个 A53内核)。

Unknown 说：

您应该能够看到 ksoftirq 线程："ps -alo psr、policy、priority、pid、tid、cputime、comm | grep ksoft"。 这些线程与处理以太网中断相关、因此我们建议尝试提升优先级、并将调度策略更改为更适合实时的调度策略。[/QUOT]

如果您可以看到 ksoftirq、并测试了它们的优先级提升的性能、请告知我们。

[报价用户 id="605944" url="~/support/processors-group/processors/f/processors-forum/1404677/am6422-prp-throughput-on-linux "]

PRP 吞吐量是通过将两个 SK-AM64B 相互连接而测得的。
iperf 客户端-服务器通信的测量吞吐量约为300Mbps。

-主板上的两个以太网端口连接到通信伙伴的端口、中间没有 L2SW。
-在 Linux 驱动程序中实现的 PRP 堆栈用于 PRP 的非卸载模式。
使用的 SDK 为09.02.01.09 (2024年3月29日)。
-在没有 PRP 的普通单电缆连接中,吞吐量超过800Mbps。

[报价]

只是为了澄清一下、您的测试设置是否符合以下条件？ 即、您能否分享测试拓扑的示意图？

电路板1：SK-AM64B 端口0 <>端口0 SK-AM64B (电路板2)

电路板1：SK-AM64B 端口1 <>端口1 SK-AM64B (电路板2)

-道林

尊敬的 Daolin：

首先是纠正。 我在我的原始帖子中犯了一个错误。
在开始的标题中、我应该写入 AM6442而不是 AM6422。 抱歉。
你能解决这个问题吗？

Unknown 说：

您选择 AM64x 而不是 AM62x 的具体原因是什么？

我们所需的 CPU 板必须能够在高温和低温环境下稳定运行。
我听说、AM64x 是目前唯一满足此条件且可用的 SoC。

Unknown 说：

请告诉我们您是否可以看到 ksoftirqs 并测试了在优先级提升的情况下的性能。

以前我们更改为 RT 调度、并提高了 ksoftirq 的优先级、以加快接收通信的速度。
然而,仅仅提高 ksoftirq 的优先级就破坏了其他内核进程的处理顺序,导致了一些无法理解的系统错误。
你知道如何安全地提高 ksoftirq 的优先级吗?

Unknown 说：

为了澄清一下、您的测试设置是否符合以下条件？ 例如、您能否分享测试拓扑的示意图？[/QUOT]

是的、是这样。
我已经为我们的测量环境拍摄了一张照片、并将其发送给您以供参考。

Unknown 说：

我最近还不能在我的环境中测试 PRP、但我将在星期五或下周早些时候尝试进行测试。 如果我能够复制您看到的性能、我还需要与开发团队核实是否有任何改进 PRP 非卸载实施的计划。 [报价]

我们期待收到您关于上述问题的答复。

提前感谢您。
此致、
大野武志

[/quote]

尊敬的 Daolin：

Unknown 说：

得到了、我刚在帖子中修改了部件号。

谢谢你的麻烦。

Unknown 说：

您将 ksoftirqs 提升至什么优先级？

在回答之前、我有一个问题。
您期望通过将 ksoftirqs 提高到最大值98、从当前值提高吞吐量多少？
由于过程与吞吐量测量过程无关、因此 CPU 负载为2-3%。
正如我之前报告的那样、刚好在开始吞吐量测量之前的 CPU 负载为2-3%。
因此,我预计当 ksoftirqs 提高到最大值98时,吞吐量的提高最多为2-3%。
我的想法是否正确？

Unknown 说：

与此同时、如果可能的话、您能否准确分享您运行 EVM 启动以测试 CPU 负载和吞吐量所运行的命令、以便在我执行此操作后可以进行比较？

虽然我们感谢您的考虑、但我们希望您尽快向我们提供结果、
我们将向您发送适用于我们的环境的命令执行过程。
(1)在客户端上启动 Linux 后的网络和 PRP 设置：setPRP_client.sh

(2)在服务器上启动 Linux 后的网络和 PRP 设置：setPRP_server.sh

(3) PRP 性能测量程序：HowToUse_measurementPRP.txt
但是、在测量吞吐量时、请停止 CPU 负载测量和 tcpdump 执行、这可能会影响测量。
・客户端脚本：measurementPRP_client.sh
・服务器脚本：measurementPRP_server.sh

大野武志

e2e.ti.com/.../MeasurementProcedure.zip

您好、Takeshi

感谢您的耐心。 在 CPSW 以太网接口上设置 PRP (对于我来说这是在 TMDS64EVM 上)时、我能够看到类似的结果为~300Mbps 吞吐量速率。

拓扑：

TMDS64EVM1 eth0 <>TMDS64EVM2 eth0

TMDS64EVM1 eth1 <>TMDS64EVM2 eth1

SDK 版本：

RT-Linux 10.00.07

测试序列：

1.在 EVM1上运行 sh ./ prp_setup.sh prp eth0 eth1 192.168.1.10、其中 prp_setup.sh 来自 https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/10_00_07_04/exports/docs/linux/Foundational_Components Kernel_Drivers Network/HSR_PRP_Network.html Non_Offload？highlight=prp 中的脚本

2.在 EVM2上运行 sh ./ prp_setup.sh prp eth0 eth1 192.168.1.20

3.从 EVM1 ping EVM2并断开一条电缆路径-->不中断通信

4.使用 TCP 通信在 EVM2上设置 iperf3服务器和在 EVM1上设置 iperf3客户端,我看到下面的结果。 令人担忧的是、每次传输都会发生重试、这表明许多数据包被丢弃。 这反过来可能会影响吞吐率、从而导致低于预期的吞吐率。

EVM1 Console Log:

root@am64xx-evm:~# iperf3 -c 192.168.1.20                                                           
Connecting to host 192.168.1.20, port 5201
[  5] local 192.168.1.10 port 44482 connected to 192.168.1.20 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  26.0 MBytes   218 Mbits/sec   23   46.5 KBytes       
[  5]   1.00-2.00   sec  26.2 MBytes   220 Mbits/sec   20   36.6 KBytes       
[  5]   2.00-3.00   sec  26.8 MBytes   224 Mbits/sec   22   52.1 KBytes       
[  5]   3.00-4.00   sec  26.6 MBytes   223 Mbits/sec   22   76.0 KBytes       
[  5]   4.00-5.00   sec  32.5 MBytes   273 Mbits/sec   13   97.2 KBytes       
[  5]   5.00-6.00   sec  38.9 MBytes   326 Mbits/sec   32   81.7 KBytes       
[  5]   6.00-7.00   sec  38.8 MBytes   325 Mbits/sec   11   98.6 KBytes       
[  5]   7.00-8.00   sec  39.6 MBytes   332 Mbits/sec   14   80.3 KBytes       
[  5]   8.00-9.00   sec  39.8 MBytes   333 Mbits/sec   12   69.0 KBytes       
[  5]   9.00-10.01  sec  38.8 MBytes   322 Mbits/sec   12   80.3 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.01  sec   334 MBytes   280 Mbits/sec  181             sender
[  5]   0.00-10.01  sec   334 MBytes   280 Mbits/sec                  receiver

iperf Done.
root@am64xx-evm:~# 

我尝试过的其他一些操作是

1、将 iperf3优先级改为60 ,并将策略从循环到 FIFO ->吞吐量稍微提高到~450Mbps

2.将 ksoftirq0和 ksoftirq1的优先级更改为70、并将策略从 Time Slice 更改为 FIFO -->未导致吞吐量发生任何明显变化

Unknown 说：

您之所以选择 AM64x 而不是 AM62x 是否有特殊原因？

Unknown 说：

我们需要的 CPU 板是一款在高温和低温环境下均可稳定运行的电路板。
我听说、满足此条件且目前可用的唯一 SoC 是 AM64x。

我可以问您从哪里听说过此信息吗？ 比较 AM64x 和 AM62x 的数据表、两者的温度范围是相同的。

AM62x： https://www.ti.com/document-viewer/AM625/datasheet#GUID-086D5402-AAEC-4ED6-B0BD-CFF7E4FE15D5/TITLE-SPRSP56INT_SPRS858_PACK_00005

AM64x： https://www.ti.com/document-viewer/AM6442/datasheet#GUID-CD6E613A-70C1-4449-8B74-B692CA434DE6/TITLE-SPRSP56INT_SPRS858_PACK_00005

我们之所以将 AM62x 作为更好的选择、原因在于更高的 CPU 频率和内核数量、这可能会提高吞吐量性能。

您尝试为什么终端设备实现 PRP？ 如果您可以访问某些 AM62x SK-EVM、尝试比较 AM62x 上的 PRP 性能可能会很有用。

-道林

尊敬的 Daolin：

也感谢您在贵公司进行测量。
我感到欣慰的是,你得到了同样的结果。

Unknown 说：

4. 使用 TCP 通信在 EVM2上设置 iperf3服务器、在 EVM1上设置 iperf3客户端、我看到以下结果。 令人担忧的是、每次传输都会发生重试、这表明许多数据包被丢弃。 这反过来可能会影响吞吐率、从而导致低于预期的速率。

在我的测量中、我观察到丢包、但很少发生、因此我认为对吞吐量的影响很小。

Unknown 说：

1. 将 iperf3优先级更改为60、将策略从轮询更改为 FIFO -->将吞吐量略微增加到~450Mbps[/QUOT]

您的成绩令我感到惊讶。
吞吐量提高了略低于50%。
我将在相同条件下进行测量。
但是、此处使用的 RT-Linux 版本是09.02.01.09。

Unknown 说：

请问您是从哪里得知此信息的吗？ 比较 AM64x 和 AM62x 的数据表、二者的温度范围是相同的。[/QUOT]

当然、您说的是正确的。
现在、我将检查信息的真实性。 我可能误解了一些东西。
请稍等片刻。

此致、
大野武志

[/quote]

尊敬的 Daolin：

Unknown 说：

1. 将 iperf3优先级更改为60、将策略从轮询更改为 FIFO -->将吞吐量略微增加到~450Mbps[/QUOT]

我们在我们的环境中执行了与上述相同的测量、但没有看到您的吞吐量得到改善。
我们的结果与上次的吞吐量大致相同。

因此、我有三个问题要问您：

1.我已经附上了我们的测量文件,但我们的测量和您的程序之间有什么区别?
-虽然评估板的类型是不同的,我认为性能几乎是相同的。
-我把 SDK 版本从09.02.01.09更改为10.00.07,结果是一样的。

e2e.ti.com/.../FIFO_5F00_SchedulingPolicy.zip

2.您能通过重复该过程多次观察到450Mbps 的吞吐量吗?
我想知道您测量的吞吐量会有哪些波动、所以请告诉我最大和最小吞吐量。

3.为何您认为上述更改提高了您的吞吐量?
与测量相关的处理之外的处理仅占 CPU 负载的几个百分点。
即使如此、上述变化也使其降低了近50%。
因此、我认为这不是由于提高了优先级。
如果更改为 RT-Linux 的 FIFO 调度策略、是否可能更改线程等待和同步机制？

Unknown 说：

请问您是从哪里得知此信息的吗？ 比较 AM64x 和 AM62x 的数据表、二者的温度范围是相同的。[/QUOT]

我所解释的信息是在 AM62x 规格公布之前提供的。 我的道歉。
即使现在、选择 AM64x 的原因是它有四个以太网端口。
另一方面、AM62x 只有两个端口。
我不是硬件专家、但很难将 AM62x 上的端口数量增加到四个。

此致、
大野武志

[/quote]

尊敬的 Daolin：

感谢您再现~450Mbps 吞吐量测试。

Unknown 说：

我需要与内部团队核实、以了解观察到的吞吐量低于预期的原因是否还有其他想法。 我的目标是在本周晚些时候提供更新。

我正在等待你的更新,但我没有听到任何消息。
我已经通过 AM6442测量得出以下结论。 是这样吗？
- PRP 吞吐量限制为~320Mbps。
-我不能再现~450Mbps 吞吐量。 我认为一定有某种错误。

[报价 userid="576780" url="~/support/processors-group/processors/f/processors-forum/1404677/am6442-prp-throughput-on-linux/5418895 #5418895"]

您是否能够使用"ps -alo psr、policy、priority、pid、tid、cputime、comm | grep iperf"仔细检查 iperf3配置的计划策略和优先级？

[报价]

对于客户端和服务器、上述命令的输出如下。 是这样吗？
1 FF -61 7595 7595 00：00：01 iperf3.

Unknown 说：

然而、理论上、吞吐量的主要改进应该来自优先级(优先级越高、吞吐量越高、理论行为越好)。

我们相信你的上述理论在以下情况下不适用。 你不同意吗？
在只有一个特定进程使用大部分 CPU 而其他进程几乎不使用 CPU 的情况下、
该进程的执行情况不会改变该进程的优先级是高还是低。

4.基准 CPSW CPU 负载
0[########***** 66.9%]任务：34、16 THR、119kTHR；0正在运行
1[………………………………………… 86.0%]平均负载：1.38 0.70 0.28
MEM[||||| #@$$$$$$$$$$$$$$$$$ 114M/1.78G]正常运行时间：00：02：52
SWP[0K/0K]
[Main][I/O]

请告诉我在您的环境中使用 iperf3测量 CPU 负载的过程。
使用什么 Linux 命令来执行上述输出？
我们的测量过程使用 vmstat 命令、
在执行 iperf3之前和期间两个点运行 vmstat、
并根据​​输出的两个 CPU 负载值的增加量计算 CPU 负载。

[报价 userid="576780" url="~/support/processors-group/processors/f/processors-forum/1404677/am6442-prp-throughput-on-linux/5418895 #5418895"]

1.基准 CPSW (无 PRP) CPU 负载=~35.8%

2.基准 PRP CPU 负载=~77.2%

FIFO 优先级85 CPU 负载=~17.6%

[报价]

上面测量的 iperf3的 CPU 负载率都低于我们的负载、CPU 处于负载下。
在本例中、您认为 iperf3/PRP 吞吐量的瓶颈在哪里？
根据我们使用 vmstat 的测量结果、当 iperf3/PRP 的吞吐量为300Mbps 时、CPU 负载超过90%。
基于这些结果、我们认为吞吐量瓶颈在于 CPU 处理能力。

我有三个新问题。
-计划于2025年上半年实施的 AM6442的 PRP 卸载功能能否同时与 PRU-ICSSG 和 CPSW3g 配合使用?

-我想尽快知道使用 PRP 卸载功能的 iperf3吞吐量值。
 您何时能提前提供测试版？
 如果难以提供、请告诉我们设计时估算的性能目标值。
- PRP 卸载功能是否支持通过改进当前 PRP 实施来提高性能的实施?

此致、
大野武志

您好、Takeshi

Unknown 说：

我正在等待您的更新、但我没有听到任何消息。

谢谢后续、抱歉延迟响应、我仍未了解有关该吞吐量约为~300Mbps 的任何有用信息。 我目前尝试了解的是吞吐量与 CPU 负载之间的关系。

Unknown 说：

因此、我从 AM6442测量结果中总结了以下内容。 是这样吗？
- PRP 吞吐量限制为~320Mbps。
-我不能再现~450Mbps 吞吐量。 我认为一定会有某种错误

是的、这是正确的、我无法复制~450Mbps 吞吐量。

Unknown 说：

对于客户端和服务器、上述命令的输出如下所示。 是这样吗？
1 FF -61 7595 7595 00：00：01 iperf3[/报价]

这是正确的并与我将 iperf3配置为 FIFO 和优先级60时看到的内容相匹配。

Unknown 说：

我们认为上述理论在以下情况下不适用。 你不同意吗？
在只有一个特定进程使用大部分 CPU 而其他进程几乎不使用 CPU 的情况下、
无论该进程的优先级是高还是低、该进程的性能都不会改变。

是的、我明白您的观点。 如果提高优先级不会影响吞吐量、那么从您的角度来看、您认为如果 CPU 负载降低、这反过来也会提高吞吐量？

Unknown 说：

请告诉我在您的环境中使用 iperf3测量 CPU 负载的步骤。
使用什么 Linux 命令来执行上述输出？
我们的测量过程使用 vmstat 命令、
在执行 iperf3之前和期间两个点运行 vmstat、
并根据​​输出的两个 CPU 负载值的增加量计算 CPU 负载。[/QUOT]

在两个 EVM 上设置 PRP

2.使用提升的优先级(优先级85)运行 iperf3

3.运行 HTop 以查看 CPU 负载。 此 Linux 实用程序工具应该已经包含在 SDK 的文件系统中、并且可以用于查看当前实时运行的所有进程的相关信息。 有关 htop 的信息： https://htop.dev/ 

4.将从 htop 到 PRP 的 CPU 负载与未设置 PRP 的情况(基线 CPSW)和不提升优先级的 iperf3的情况(基线 PRP)进行比较

Unknown 说：

上面测得的 iperf3的 CPU 负载率均低于我们的负载、且 CPU 处于负载状态。
在本例中、您认为 iperf3/PRP 吞吐量的瓶颈在哪里？
根据我们使用 vmstat 的测量结果、当 iperf3/PRP 的吞吐量为300Mbps 时、CPU 负载超过90%。
根据这些结果、我们认为吞吐量瓶颈在于 CPU 处理能力。[/QUOT]

您能展示运行的结果吗  HTop (将整个输出显示为快照)。 我想知道您是否可能在后台运行其他一些进程、导致您报告的 CPU 负载较高。

Unknown 说：

计划于2025年上半年实施的 AM6442 PRP 卸载功能能否同时使用 PRU-ICSSG 和 CPSW3g？

[/quote]

据我所知、PRP 卸载功能将专门针对 PRU-ICSSG 以太网接口进行调度。 这是因为卸载功能将卸载到 PRU 内核、而这可通过 PRU-ICSSG 接口完成。 这是当前处理 HSR 卸载的方式。

我想问一下、为什么要关注 PRP 拓扑而不是 HSR 拓扑？  

Unknown 说：

您什么时候可以提前提供测试版？
 如果难以提供、请告诉我们设计时估算的性能目标值。
- PRP 卸载功能是否支持通过改进当前 PRP 实施来提高性能的实施?[/报价]

根据我的理解、由于 PRP 卸载功能仍在开发中、我们目前没有可以提前共享版本的日期。 我可以检查是否存在性能目标值、但我猜测性能将与 HSR 卸载性能相似。  

-道林

[/quote][/quote][/quote]

• 取消

• 向上 0 True 向下
• 取消

Unknown 说：

我目前尝试了解的是吞吐量与 CPU 负载之间的关系。

我们希望您的两个 iperf3/PRP 测量结果与我们的相同。
您的通信吞吐量测量结果约为300Mbps、因此没有问题。
另一方面、您的 CPU 使用情况测量结果与我们的不同。 我们认为、原因在于测量方法的差异。
我们还尝试了您使用的 htop 命令。
此命令的输出屏幕存在问题、当 CPU 负载较高时会延迟一段时间更新、因此我们确定此命令不能正确显示 CPU 使用情况。
因此、建议您使用与我们相同的 vmstat/mpstat、以准确测量 CPU 使用率。
vmstat 输出每个内核的平均 CPU 使用量、而 mpstat 还输出每个内核的 CPU 使用量。
因此、我们希望您使用 mpstat 测量 CPU 使用率、如下所示。
- mpstat -p all 1.

我们还希望您至少测量数据接收端(即服务器)的 CPU 使用率。
原因是、根据我们的测量结果、服务器的 CPU 负载在客户端计算机的 CPU 负载之前达到了上限。
(服务器的 CPU 使用率达到90%或更多。)
服务器的接收过程是通信吞吐量的瓶颈。
在不使用 PRP 测量 iperf3吞吐量时观察到了相同的现象。
由此给您带来的不便、我们深表歉意、但请确保您的环境中也能看到相同的现象。

具体而言、我们希望您测量您环境中服务器计算机上以下两种 CPU 使用情况。 两个 CPU 使用率的增加将是 iperf3/prp 的 CPU 使用率。
1.在运行 iperf3/PRP 之前测量 CPU 使用率。
 如果 CPU 使用率超过2-3%、请检查是否有测量不需要的进程正在运行。
 如果较高、则停止不必要的过程。
2.在运行 iperf3/PRP 时测量 CPU 使用率。
 您应该能够确认 CPU 使用率达到或超过90%、与我们的相同。

[报价 userid="576780" url="~/support/processors-group/processors/f/processors-forum/1404677/am6442-prp-throughput-on-linux/5431266 #5431266"]

您能展示运行的结果吗  HTop (将整个输出显示为快照)。 我想知道您是否可能在后台运行其他一些进程、导致您报告的 CPU 负载较高。

[报价]

在我们的环境中、执行 iperf3/PRP 时、没有启动与 iperf3/PRP 无关的流程。 (请参阅随附文件)

Unknown 说：

如果提高优先级不会影响吞吐量、那么从您的角度来看、您认为如果降低 CPU 负载、也会提高吞吐量？

这不准确。
这里我们要说的是、如果不执行除 iperf3/PRP 之外的处理、仅由于与 iperf3/PRP 相关的处理而使 CPU 使用率达到90%或以上、
然后、无论 iperf3/PRP 的优先级设置得有多高、吞吐量都不会提高。

Unknown 说：

我想问为什么 PRP 拓扑对 HSR 拓扑感兴趣？  [报价]

对于 HSR、沿环的顺时针和逆时针路线进行通信。
例如、当与环形右侧的机器通信时、通过直接路由与该机器通信的延迟比反向路由小得多。
因此、从直接路由到达的帧将首先被接收、而从反向路由到达的帧将被延迟、因此它们成为重复帧并被丢弃。
如果路由故障导致直接路由断开连接、则路由将切换到反向路由、通信延迟将显著增大。
由于我们需要端到端实时通信、因此我们选择了 PRP、这样即使在切换路由的情况下、通信延迟也能保持恒定。

此致、
大野武志

您好、Takeshi

感谢您对 CPU 负载差异和 PRP 拓扑使用的合理解释。

我将尝试按照您在周五或下周初所描述的那样运行这些测试(我不在办公室、周二至周四)。

-道林

尊敬的 Daolin：

感谢您向我们发送您的 CPU 使用情况测量数据。
您的测量结果与我们的测量结果几乎相同。
我们已经得出以下关于在非卸载 PRP/iperf3执行中使用两个内核的结论：
(1)数据接收端(服务器计算机)是吞吐量瓶颈、因为两个内核的使用率几乎处于上限。
(2)当时用户线程的两个内核的使用率仅为几个百分点、因此内核线程 PRP 处理和接收处理几乎占用了两个内核。

我们还测量了非负载 HSR/iperf3的吞吐量和 CPU 使用率。

我们的测量环境如下所示。
-两个 TMDS64GSEVM 被用作评估板。
 两个端口(eth1、eth2)通过以太网电缆直接连接、如附图所示。
-使用了 SDK 09.02.01.09。
- eth1默认连接到 CPSW3g、所以我们通过以下设置将其更改为 PRU-ICSSG。
 software-dl.ti.com/.../PRU_ICSSG_Ethernet.html
-使用了以下 Linux 设置:
 software-dl.ti.com/.../HSR_Offload.html

针对该环境的测量结果如下：
- iperf3吞吐量为450Mbps。 这比非关断负载 PRP 好约1.5倍。
-当时的 CPU 使用率约为80%。 CPU 使用率比非空载 PRP 低10%

我们对这一结果的看法如下：
-可以说,卸载 PRP 的吞吐量几乎等于卸载 HSR 的测量结果。
 原因是当两个评估板直接连接时、环形拓扑和树形拓扑没有区别。
 换句话说、当两个电路板直接连接时、不会发生发送到其他机器的中继帧(特定于环形拓扑)的过程。
-为什么吞吐量是450Mbps 的原因是执行卸载 HSR 的 PRU-ICSSG 预计是瓶颈。
 为了进一步改进、有必要审查分离负载 HSR 的编程并提高处理效率。
-卸载 HSR/iperf3的 CPU 使用率在逻辑上应与 iperf3的 CPU 使用率相同,后者不使用 HSR,因为 HSR 由 PRU-ICSSG 处理。
 换句话说、当吞吐量为450Mbps 时、非负载 HSR/iperf3的 CPU 使用量应与 CPU 使用量(45%)相同、只有 iperf3在没有 HSR 的情况下使用。
 不过、我们可以预测两者之所以不同、是因为从 PRU-ICSSG 到 CPU 的数据传输不是 DMA 传输、而是使用 CPU 进行的传输。

请指出我们在上述想法中存在的任何错误或误解。
我们还希望您确认卸载 HSR/iperf3是否会在您的环境中产生相同的结果。

此致、
大野武志

您好、Takeshi

我想更正我之前对下面内容的评论。 由于卸载的 HSR 是根据 PRU_ICSSG 而不是 CPSW 执行的、因此具有单个内部主机端口的 CPSW 端口的物理限制不应应用于 PRU_ICSSG。

我 猜测、观察到的吞吐量可能是由于内核具有支持重复数据流的处理能力。 我不确定这是否是 A53内核或 PRU 上的瓶颈、因为 A53内核的结果是~80%的负载、因此不太能达到大于90%的负载。  

[报价 userid="576780" url="~/support/processors-group/processors/f/processors-forum/1404677/am6442-prp-throughput-on-linux/5470644 #547064"]

我不知道我是否完全同意以下说法、因为当两个以太网接口(没有任何 HSR 或 PRP 设置)都有流量通过 iperf3时、也会观察到~450Mbps 吞吐量。 我认为产生这种吞吐量的原因在于、流量通过的两个以太网接口之间必须共享1Gbps 的线路速率(无论是配置为 HSR/PRP 的两个接口、还是仅配置为传输流量的标准2个以太网接口)。 换句话说、只要两个以太网接口同时使用、就不太可能获得比~450Mbps 更高的吞吐量。  

大野武志说：

-为什么吞吐量是450Mbps 的原因是执行卸载 HSR 的 PRU-ICSSG 预计是瓶颈。
 为了进一步改进、有必要审查分离负载 HSR 的编程并提高处理效率。

[报价]

-道林

Unknown 说：

在此设置中、只有2个设备直接连接(从源设备直接连接到目标设备而不使用转发/桥接设备)、从逻辑上讲、不需要 HSR 交换卸载、这是 HSR 和 PRP 之间卸载功能的主要区别。 HSR 和 PRP 之间重复插入、重复移除等的其他卸载类似、这可能导致 HSR 卸载与非卸载 PRP 相比、CPU 负载降低了~10%。  [报价]

根据您的上述说明、我们对 HSR 和 PRP 之间的区别以及卸载 PRP/HSR 和非卸载 PRP/HSR 之间的区别有着相同的看法。
但是、对于 HSR 卸载期间接收计算机80%的高 CPU 使用率、没有逻辑解释。
原因是在 HSR-offload 期间接收计算机上、不应由 CPU 执行 tag-rm-offload、fwd-offload 和 dup-offload 三个进程、而应由 PRU-ICSSG 芯片执行。
由于这些进程包含大多数 HSR 进程、我们预计在使用 HSR-offload 时、CPU 的使用量理论上与不使用 HSR 时的 CPU 使用量几乎相等。

当两个 TMDS64GSEVM 相互连接时、不使用 HSR/PRP 时的 iperf3吞吐量约为900Mbps、而接收机当时的 CPU 使用率约为90%。
此外、如果使用-b、--bandwidth 选项将 iperf3吞吐量限制为450Mbps、则 CPU 使用率将下降到大约一半。
请确认您在您的环境中获得类似的结果。

根据这些测量结果、我们预计、由于使用 HSR-offload 时的 iperf3吞吐量为450Mbps、因此接收机的 CPU 使用率在逻辑上等于上述450Mbps CPU 使用率。
我们不认为使用 HSR-offload 时吞吐量限制在450Mbps 这一事实成为问题。  
另一方面、我们确实要考虑这样一个事实、即在使用 HSR-offload 时、CPU 的使用量很高、为80%、比理论值低30%以上。
我们希望你考虑的原因,即使它只是一个假设。
例如、接收机器的 CPU 用于将接收到的数据从 PRU-ICSSG 芯片传输到 CPU。

我们的目标是使用您的 AM6442充分发挥其功能。
感谢您的合作。

此致、
大野武志

您好、Takeshi

[报价 userid="605944" url="~/support/processors-group/processors/f/processors-forum/1404677/am6442-prp-throughput-on-linux/5486928 #5486928"]当两个 TMDS64GSEVM 相互连接时、不使用 HSR/PRP 时的 iperf3吞吐量约为900Mbps、而当时接收计算机的 CPU 使用率约为90%。

这是仅一个以太网端口/接口传输 iperf3流量的结果还是两个以太网接口/端口同时传输流量的结果？ 当只有一个以太网端口/接口传输流量时、我预计会看到900Mbps、但两个端口都运行时则不然。

当我运行时同时有两个以太网接口/端口(PRU_ICSSG 以太网端口)传递流量时、我看到吞吐量约为400Mbps。 这只适用于 iperf3 (无 PRP 或 HSR 配置)。 客户端 EVM 上的负载约为80%、服务器 EVM 上的负载约为90%。

Unknown 说：

但是、对于 HSR 卸载期间接收计算机80%的高 CPU 使用率、没有逻辑解释。
原因是在 HSR-offload 期间接收计算机上、不应由 CPU 执行 tag-rm-offload、fwd-offload 和 dup-offload 三个进程、而应由 PRU-ICSSG 芯片执行。
由于这些进程包含大多数 HSR 进程、因此我们预计、在使用 HSR-offload 时、CPU 的使用量理论上与不使用 HSR 时的 CPU 使用量几乎相等。[/QUOT]

我认为在 HSR 循环中源器件和目标器件上看到~80%负载的原因是运行了 iperf3、而不是 HSR 进程。 例如、如果测试使用3个 EVM、1个 EVM 作为源/iperf3客户端、1个 EVM 作为目标/iperf3服务器、以及1个 EVM 将流量从源转发到目标、则转发 EVM 上的负载约为2%、与未运行 HSR 时 CPU 使用率的情况接近。 所有3个 EVM 都将运行卸载的 HSR、唯一的区别是源 EVM 和目标 EVM 运行 iperf3、而转发 EVM 未运行 iperf3。

这也与我在使用中的两个以太网端口运行 iperf3 (无 HSR 或 PRP)的结果相符。 CPU 负载也约为80%、只有 iperf3是主应用程序运行。  

-道林

您好、Takeshi

Unknown 说：

PRP 卸载支持目前计划于2025年上半年提供。

此外、我想澄清我所作的这一发言。 很可能计划为 RTOS 发布 PRP 卸载支持。 通常、对于真正的实时要求、使用 RTOS 是更好的解决方案。 您是计划使用 RTOS 还是在 RT-Linux 中实现 PRP (或 HSR)？

-道林

尊敬的 Daolin：

很抱歉这么晚才回复。 我生病了,住院了一个星期,但我现在恢复了。

Unknown 说：

这款900Mbps 是仅一个以太网端口/接口传递 iperf3流量还是两个以太网接口/端口同时传递流量？ [报价]

仅使用一个以太网端口/接口时、该吞吐量为900Mbps。

[报价 userid="576780" url="~/support/processors-group/processors/f/processors-forum/1404677/am6442-prp-throughput-on-linux/5487739 #5487739"]

当只有一个以太网端口/接口传输流量时、我预计会看到900Mbps、但两个端口都运行时则不然。

当我运行时同时有两个以太网接口/端口(PRU_ICSSG 以太网端口)传递流量时、我看到吞吐量约为400Mbps。 这只适用于 iperf3 (无 PRP 或 HSR 配置)。 客户端 EVM 上的负载约为80%、服务器 EVM 上的负载约为90%。

[报价]

我们还认为、上述结果是正确的。
无论使用一个还是两个以太网端口、我们预测服务器 EVM (数据接收机)的总接收数据吞吐量都将限制为900Mbps。
原因是服务器 EVM 的 CPU 利用率几乎为90%、这是以900Mbps 速率接收数据的上限。
因此、如果将服务器 EVM 上的接收数据吞吐量调整为450Mbps、则服务器 EVM 的 CPU 利用率几乎为50%或更低。
通过这种方式、接收数据吞吐量与服务器 EVM 的 CPU 利用率之间存在大致成比例的关系。

Unknown 说：

我认为 HSR 循环中源设备和目标设备上出现~80%负载的原因在于运行 iperf3、而不是由于 HSR 进程。 [报价]

根据我上面的说明、在使用 HSR 卸载的服务器 EVM 上、450Mbps iperf3所需的 CPU 利用率理论上应小于50%。
但是、实际 CPU 利用率要比理论值高30%。 请与 HSR 卸载的设计人员和实施者讨论原因。

Unknown 说：

这也与我在使用两个以太网端口的情况下运行 iperf3 (没有 HSR 或 PRP)得到的结果相符。 CPU 负载也约为80%、只有 iperf3是主应用程序运行。  [报价]

您的上述解释是否正确？
当使用 HSR 卸载功能时、HSR 处理由 PRU_ICSSG 芯片执行、因此即使两个以太网端口每个端口以450Mbps 的速率接收、重复的帧也应由 PRU_ICSSG 芯片丢弃。
因此、服务器 EVM 的 CPU 应该只需要执行450Mbps 接收处理。

我们认为您的上述解释不足以说明 CPU 利用率为何为80%。
我们担心 HSR 卸载的实现是否存在任何问题。
因为关于 PRP 卸载也可以说相同的事情、计划在2025年提供。
我们还有一个请求。
当您解释 HSR 卸载时、请以我们的两个 EVM 使用相同的环配置为例来简化说明。
这是因为采用两个 EVM 的环配置中的 HSR 处理几乎相当于 PRP 处理。

此致、
大野武志   

[/quote]

[/quote][/quote]

尊敬的 Daolin：

Unknown 说：

我们从未对 PRP 支持的特定吞吐量性能进行过任何基准测试。 由于这个原因以及您的结果和我的结果返回 PRP 大约300Mbps 吞吐量(当前仅提供非卸载功能)、PRP 吞吐量可能被限制在大约300Mbps。  [报价]

由于以下原因、我们决定 PRP 非断开负载将不符合我们的要求。
-使用1Gbps 网络时,我们最多只能使用30%。
 由于数据是输出到两条路由、因此我们希望吞吐量超过网络带宽的50%。
-此外,当时 AM6442 CPU 使用率为90%,没有备用 CPU 容量。
 我们希望将用于通信处理的 CPU 使用率保持在20%或更低、并将剩余的80%用于应用处理。

因此、如果我们使用非负载 PRP、则需要将吞吐量限制为60Mbps、即300Mbps 的20%。
这不符合我们的要求。

Unknown 说：

是否有需要满足的特定延迟阈值？ 我提出这 一问题的原因是、我们需要在以下选项之间进行评估、以确定我们是否应该重点实施哪种功能/解决方案来解决您的用例问题。[/QUOT]

此外、HSR 的问题不是实时通信本身的延迟、而是通信路径中故障导致的延迟波动较大。
换句话说、实时通信的延迟可以是几十毫秒、但我们希望延迟波动保持在延迟的10%以内。

对于这两点、唯一可以满足要求的实现是 PRP 卸载。

Unknown 说：

很可能计划为 RTOS 发布 PRP 卸载支持。 通常、对于真正的实时要求、使用 RTOS 是更好的解决方案。 您是计划使用 RTOS 还是在中与 RT-Linux 一起实现 PRP (或 HSR)？[/QUOT]

我们选择 RT-Linux 而不是 RTOS。
因此、我们强烈希望尽快提供在 RT-Linux 上运行的 PRP 卸载功能。

此致、
大野武志   

[/quote]

[/quote][/quote]

道林武志山目前正在商务旅行加上一些休息时间。 那么响应可能会延迟。 感谢您的理解

Paula.

https://www.ti.com/product/DRA821U 器件具有4个以太网端口和足够的计算能力来支持该数量的端口和 RT-Linux。

 Pekka

尊敬的 Pekka：

感谢您提供有关 DRA821U 的有用信息。
它符合我们的温度条件和以太网端口号要求、CPU 性能是 AM6442的两倍以上。
DRA821U 是何时发布的？
是否有可能获得适用于 DRA821U 的评估板？

此致、
大野武志

是 https://www.ti.com/product/DRA821U 已经 开始量产、评估板可在 https://www.ti.com/product/DRA821U#design-development 上获取。 其样片于2022年推出、自2023年开始投入生产。

 Pekka

尊敬的 Pekka：

感谢您的答复。
我想询问硬件专家为什么没有选择 DRA821U。
在任何情况下、对我们来说、AM6442以外的选项都是面向未来的。
就目前而言、找到采用 AM6442和 RT-Linux 的最佳解决方案至关重要。
我期待着道林山的答复。

此致、
大野武志

Unknown 说：

目前、找到使用 AM6442和 RT-Linux 的最佳解决方案至关重要。
我期待着 Daolin-San 的回复。

Unknown 说：

我们选择 RT-Linux 而不是 RTOS。
因此、我们强烈希望尽快提供在 RT-Linux 上运行的 PRP 卸载。

目前在 Linux 中没有针对 AM64x 的 PRP 卸载提交计划。 这不是道林能够改变的。 具有 RTOS 的 MCU+计划在2025年第1季度加入 PRP。 TI 没有计划在2025年编写 Linux 驱动程序、上游数据流以及解决与这个卸载相关的所有依赖项。

 Pekka  

您好、Takeshi

感谢您在我外出时的耐心等待。

[报价 userid="605944" url="~/support/processors-group/processors/f/processors-forum/1404677/am6442-prp-throughput-on-linux/5509681 #5509681"]

邱道林说：

这也与我在使用中的两个以太网端口运行 iperf3 (无 HSR 或 PRP)的结果相符。 CPU 负载也约为80%、只有 iperf3是主应用程序运行。  

您的上述解释是否正确？
当使用 HSR 卸载功能时、HSR 处理由 PRU_ICSSG 芯片执行、因此即使两个以太网端口每个端口以450Mbps 的速率接收、重复的帧也应由 PRU_ICSSG 芯片丢弃。
因此、服务器 EVM 的 CPU 应该只需要执行450Mbps 接收处理。

我们认为您的上述解释不足以说明 CPU 利用率为何为80%。
我们担心 HSR 卸载的实现是否存在任何问题。
因为关于 PRP 卸载也可以说相同的事情、计划在2025年提供。

[报价]

我要说明的一点是、80%的负载可能与任何 HSR 处理无关。 无论是否配置了 HSR、客户端/服务器的 CPU 负载仍保持约80%的负载。 这意味着 EVM 的 CPU 内核占用了太多的负载来处理~400Mbps 发送/接收处理。 因此、我认为80%的负载与 HSR 卸载实现无关、只是处理以太网数据包时会看到的负载。

简而言之、在接收路径方面、以太网数据包在 FIFO 缓冲区中接收、每个缓冲区都包含描述符、这些描述符需要使用 CPU 内核进行处理。 发送路径将使用类似的处理方案、但方向相反。 无论是否配置了 HSR 卸载、客户端/服务器器件都会发生这种情况。  

Unknown 说：

目前、找到使用 AM6442和 RT-Linux 的最佳解决方案至关重要。
我期待着 Daolin-San 的回复。

Unknown 说：

此外、HSR 的问题不在于实时通信本身的延迟、而在于通信路径故障导致的延迟大幅波动。
换句话说、实时通信的延迟可以是几十毫秒、但我们希望延迟波动保持在延迟的10%以内。

user4068379 说：

目前没有针对 AM64x 在 Linux 中执行 PRP 卸载的确切时间表。

简而言之、当前没有计划在 Linux 上改进 PRP 卸载或 PRP 非卸载。 因此、对于 AM6442和 RT-Linux 解决方案、我们更可能选择使用 HSR。 对于 HSR、我怀疑延迟的波动也与拓扑中配置的器件数量以及 HSR 环中两条冗余路径上器件数量的差异有关。 您是否了解您的终端器件将支持的器件数量？ 或者这是一个任意数字吗？

-道林

Unknown 说：

PRP 卸载或 PRP 非卸载改进当前未计划用于 Linux

我想澄清的是、PRP 在 RT-Linux 上转移至 ICSSG 是我们路线图的一部分、我们将在25年第2季度解决这一问题。 当涉及 TX 重复和 RX 重复丢弃时、这在功能上与 HSR 卸载相似。

此致

Pratheesh

我们感谢您对我们的请求的考虑。
如果您能让我们知道 RT-Linux 版本的 PRP Offload 何时将在决定后立即提供给我们、我们将不胜感激。

此致
武志