[参考译文] AM4378：PRU-ETH 性能

您好 Bernd、

对延迟答复表示歉意。 AM437x Linux 内核5.10版本将支持通用 PRUETH。 此时、我尚未测试下载和上传速度。

您能否发布用于测试的说明、以便我进行验证？

此致、

Nick

您好 Nick

我是执行测量的人。 测量是使用 iperf3完成的。
按如下方式启动服务器：

iperf3 -4 -s -p 12345 -f M

然后启动客户端并执行如下测量：

iperf3 -c 192.168.0.1 -p 12345-4 -f M

添加"-R"将以反向发送/接收。
在 AM437x 板上启动服务器或客户端无关紧要。

问题：
根据您的回答、AM437x Linux 内核5.4版本不支持通用 PRUETH。 是这样吗？

感谢你的帮助

此致、Daniel

Daniel、您好！

我们在 AM437x Linux 内核5.4版本中介绍了一些 PRU 网络功能(具有 PRU 卸载功能的 HSR/PRP 和用户空间 ICSS-EMAC 驱动程序)。 请参阅 https://software-dl.ti.com/processor-sdk-linux/esd/AM437X/07_03_00_005/exports/docs/devices/AM437X/linux/Release_Specific_Release_Notes.html#release-07-03-00 )。 但是、AM437x Linux 内核5.4版本支持通用 PRUETH。

ARM 内核频率和功率设置、整体处理能力、使用 ARM 内核的其他线程数量等因素将影响处理器生成通过 ipperf/iperf3发送数据包的速率。 尽管如此、当 AM437x 在 Linux 内核4.9和 Linux 内核5.4上生成数据包时、我确实观察到吞吐量显著下降。 我还没有时间在内核5.10版本上运行测试、或者看看这些内核版本之间为什么会有差异。

请注意、我使用的是 iperf 而不是 iperf3、因为 iperf3不在 AM437x Processor SDK 4.3的默认文件系统上。

设置：使用 CAT6电缆将 AM64x EVM 直接连接到 AM437x IDK PRU 以太网端口。 AM437x 正在运行开箱即用的文件系统。

当 AM64x 处理器为 iperf3生成以太网数据包时、无论 AM437x 上运行的 Linux 版本如何、我都看到了94Mbit/s 的比特率(即线路速率)。 这是预期的。

SDK 7.3 (Linux 内核5.4)。 当 AM437x 为 iperf3生成以太网数据包时、我看到的比特率为~27 Mbit/s

root@am437x-evm:~# uname -a
Linux am437x-evm 5.4.106-g023faefa70 #1 PREEMPT Fri Jul 2 11:03:51 UTC 2021 armv7l armv7l armv7l GNU/Linux

root@am437x-evm:~# iperf -c 192.168.2.160 -p 12345
------------------------------------------------------------
Client connecting to 192.168.2.160, TCP port 12345
TCP window size: 83.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.141 port 41836 connected with 192.168.2.160 port 12345
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  32.6 MBytes  27.3 Mbits/sec

root@am437x-evm:~# iperf -s -p 12345
------------------------------------------------------------
Server listening on TCP port 12345
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 192.168.2.141 port 12345 connected with 192.168.2.160 port 60608
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.1 sec   113 MBytes  94.0 Mbits/sec

SDK 4.3 (Linux 内核4.9)。 当 AM437x 为 iperf3生成以太网数据包时、我看到比特率为~88 Mbit/s

root@am437x-evm:~# uname -a
Linux am437x-evm 4.9.69-g9ce43c71ae #1 PREEMPT Mon Mar 26 12:08:26 EDT 2018 armv7l GNU/Linux

root@am437x-evm:~# iperf -c 192.168.2.160 -p 12345
------------------------------------------------------------
Client connecting to 192.168.2.160, TCP port 12345
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.141 port 35008 connected with 192.168.2.160 port 12345
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   105 MBytes  88.3 Mbits/sec

root@am437x-evm:~# iperf -s -p 12345
------------------------------------------------------------
Server listening on TCP port 12345
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.2.141 port 12345 connected with 192.168.2.160 port 60606
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.1 sec   113 MBytes  94.2 Mbits/sec

此致、

Nick

您好 Nick

感谢您对此进行深入研究。 有没有进一步的发展
5.4内核版本？

此致、Daniel

Daniel、您好！

对延迟答复表示歉意。 我已确认 AM335x 处理器 SDK 8.2 (内核5.10)具有与内核5.4相似的性能。 遗憾的是、处理器 SDK 8.2的核心开发已经完成、因此 TI 官方版本的性能仍会降低。

但是、开发人员将在下一个 AM335x SDK 版本中解决此问题(此时、下一个 AM335x SDK 版本似乎也将在内核5.10上)。 如果他们能够找到修复程序、我们可以在下一个版本发布之前在此处发布补丁。

开发人员将重点关注内核5.10而不是内核5.4、因此补丁将针对内核5.10。 然而、似乎团队在内核5.4和内核5.10之间对 PRU 以太网驱动程序进行了大量更改、所以我希望内核5.10补丁可以重新移植到内核5.4。

此致、

Nick

您好、Nick、

感谢您提供信息。 由于5.10将与 Yocto 4.0 Kirkstone 一起使用、而 Kirkstone 是 LTS 版本、因此如果可以为其修复、这将是很好的、因为它将被使用很长时间。

此致、Daniel

您好、是的、

解锁此主题、以便我们继续对话。

似乎使用零拷贝模式可以提高性能，但您的应用程序不支持零拷贝。 是这样吗？ 您还可以提供其他详细信息吗？

我告诉开发人员、我们的零拷贝不是一种可接受的解决方法、我们需要继续处理该问题。

此致、

Nick

您好、Nick、

是的、没错。 如果我使用`-Z`标志运行 iperf3、那么线缆性能符合预期。 但遗憾的是、我们的应用程序不支持零拷贝、因此我们必须使用"正常"模式。 我使用 iperf3是因为它是一种测量带宽的简单方法。

我使用5.10内核并使用以下版本再次运行测试：
- ti-rt-linux-5.10.y 分支 commit 44a4e68ecf519fd2e35417371fbac546c416d2d9
－prueth-FW 5.1.4-r0.0

我可以提供哪些信息来提供帮助？ 您是否能够在 AM437X EVK 上重现问题？

此致、Daniel

您好、Nick、

你有更新吗？

此致、Daniel

Daniel、您好！

感谢您的 Ping 操作。 我们能够复制您的观察结果。 我还没有听到开发人员的反馈、我会再次对他们执行 ping 操作、看看我是否可以为您提供一个时间范围、以便您可以从我们那里获得更多信息。

此致、

Nick

Daniel、您好！

开发团队正在寻找有关您的用例的其他信息。 我假设您的应用中没有使用 iperf3、而是其他一些以太网软件或命令？ 您可以在此处或通过  Bernd 通过电子邮件与我们分享这些信息吗？

谢谢、

Nick

您好、Nick、
我们使用以下方法：
－Nodejs 14.17.1
－swupdate 2021.11
－蚊子到2.0.12
－opensh 8.7p1

在带宽方面最重要的是前两个。

但我想指出的是、我首先发现了 ssh 的问题。 然后、我使用 iperf3和 nodejs 进行了测试。 在我看来、问题似乎与应用无关、因为我对所有应用都有相同的行为。

您是否需要详细的步骤来重现问题？

此致、Daniel

Daniel、您好！

好的、谢谢。 我们已经使用 iperf3进行了复制、但查看您在 openssl 和 nodejs 中使用的命令可能会有所帮助、以确保任何修补程序实际上可以解决您的用例的问题。

此致、

Nick

Daniel、您好！

开发人员已开始将 Linux 4.19和 Linux 5.4之间的修补程序进行分层、以查找问题的原因。 我没有时间安排我们何时可以期待另一次更新。 我将在8月的剩余时间休假、但我的经理将会观看您的主题。 如果您需要更新、请随时执行 ping 操作。

此致、

Nick

您好、Nick、

感谢您的更新。 我将在今天晚些时候公布具体步骤，说明如何复制。

此致、Daniel

您好、Nick、

要测试这是从 node.js 下载的测试：
我之前提到过、我们将使用 node.js。 您可以如下方式对其进行测试：
-在 AM437x 板上安装 node.js (我们使用的是14.17.1)。
－将 fileserver.js (见下文)放在某个位置。
-创建随机字节的文件以供下载：
DD if=/dev/urandom of=random.dat bs=1M count=256
-启动 node.js：
节点文件服务器.js
－在另一台计算机上，使用 wget 测量下载速度：
wget 192.168.0.1：9000/random.dat
-检查速度，它将如下所示：

$ wget 192.168.0.1：9000/random.dat
2022-08-18 08：05：08 - 192.168.0.1：9000/random.dat
正在连接到192.168.0.1：9000... 互联。
HTTP 请求已发送、正在等待响应... 200正常
长度：268435456 (256M)[文本/普通]
保存到：‘random.dat’

random.dat 100%[=========================== 以72秒为单位、大于] 256.00M 3.51Mb/s

2022-08-1808:06:25 (3.53Mb/s)-‘random.dat’saved [268435456/268435456]

-使用4.9内核时，它如下所示：

2022-08-1808:14:47(11.0 Mb/s)-‘random.dat’saved [268435456/268435456]

此致、Daniel

// fileserver.js 
const http =需要('http')； 
const URL = require('url')； 
const fs = require('fs')； 
const path = require('path')； 
const 端口= process.argv[2]|| 9000； 
http.createServer (函数(req、res)｛ 
console.log (`$｛req.method｝$｛req.url｝`)； 
const parsedul = url.parse (req.url)； 
假设 pathname =`。$｛parsedurl.pathname｝`； 
fs.exists (pathname、函数(存在)｛ 
if (！exists)｛res.statusCode = 404；res.end (`file not found：$｛pathname｝`)；return；｝ 
fs.ReadFile (pathname、function (err、data)｛ 
if (err)｛res.statusCode = 500； 
Res.end (`不能读取文件：$｛err｝。`)； 
}否则{ res.setHeader('Content-type'，'application/octet-stream')； 
RES.END (data)；})；})；}.Listen (parseInt(nport))； 
console.log (`侦听端口：$｛port｝`)； 

Daniel、您好、主题负责人目前不在办公室、但下周将回来。 然后、他应该能够更新开发人员测试等的状态 此致、Andreas

Daniel：

在我们的末尾进行的测试表明、速度下降是由 PRU 以太网固件中的回归而不是内核引起的。 您能否 尝试从 v6.03 SDK 版本(也随附)中试用 AM437X-pru0-prueth-FW.elf 和 AM437x-pru1-prueth-FW.elf 并在此处报告。  文件应该会进入  

/lib/firmware/ti-pruss 



e2e.ti.com/.../am437x_2D00_prueth_2D00_firmwre_2D00_sdk_2D00_6.03.zip

此致、Andreas 

您好、Andreas、

它完全不起作用。 尽管新固件似乎加载正常、但没有通信经过。 该固件应针对哪个内核版本运行？ 我尝试了 ti-linux

-5.10.109-RT65 (08.03.00.003-RT)、用于原始测试的版本
-5.10.131-rt72 (08.04.01.003-RT)，Git 中提供了最新版本

器件树中是否需要进行任何更改？

此致、Daniel

Daniel、您好！

测试更新

我已经与 AM64x 的链接合作伙伴一起验证了您对 AM335x 的观察结果和开发人员的观察结果(行为应与 AM437x 上的 PRUETH 相同)。

运行 SDK 8.2中固件的 SDK 8.2： 链路启动、能够 ping 通、iperf3 ~29Mbit/s 的 TX 吞吐量
运行 SDK 7.3固件的 SDK 8.2：链路启动、无法 ping 通
运行 SDK 6.3固件的 SDK 8.2：链路出现、无法 ping 通

运行 SDK 8.2中固件的 SDK 7.3：链路启动、能够 ping 通、iperf3 ~26Mbit/s 的 TX 吞吐量
运行 SDK 7.3固件的 SDK 7.3：链路启动、能够 ping 通 iperf3 ~27Mbit/s 的 TX 吞吐量
运行 SDK 6.3固件的 SDK 7.3：链路启动、能够 ping 通、iperf3 ~ 90Mbit/s 的 TX 吞吐量

运行 SDK 8.2固件的 SDK 6.3：链路启动、能够 ping (长 ping 时间~1-15ms)、iperf3 ~24Mbit/s 的 TX 吞吐量
运行 SDK 7.3固件的 SDK 6.3：链路启动、能够 ping (长 ping 时间~1-10ms)、iperf3 ~30Mbit/s 的 TX 吞吐量
运行 SDK 6.3固件的 SDK 6.3： 链路启动、能够 ping (长 ping 时间~1-15ms)、iperf3 ~87Mbit/s 的 TX 吞吐量

开发人员更新  

我仍在等待从固件开发人员处获取输入、我已再次对他们执行 Ping 操作。 Linux 开发人员下周左右不能访问硬件。 当他离开他的董事会时、我仍在制定我们的计划。

仔细检查您的项目需求  

此时、我应该确保开发人员关注哪种内核版本？ 我们应该记住其他任何特定的系统需求吗？

此致、

Nick

您好、Nick、

感谢您的更新。 我们将重点介绍内核5.10-RT。

我在08.03.00.003-RT (44a4e68ecf519fd2e35417371fbac546c416d2d9)完成了我的最后一次测试。
这是 git.ti.com/.../上的 branch `ti-rt-linux-5.10.y`。
我想这比 SDK 8.2要新一点。

此致、Daniel

Daniel、您好！

明白。 我将要求团队重点关注 SDK 8.2的工作、因为它最接近您的开发分支。

状态更新：PRU 固件开发人员为我们提供了不同 SDK 版本之间的更改摘要、Linux 开发人员本周将回来。 他们开始了解 PRU 固件和 Linux 驱动程序之间的交互在固件版本之间如何变化、以查看我们是否可以从 Linux 端设置简单的内容。

我将在下周提供另一个更新。 如果我在9月28日前未提供更新、请对该主题执行 Ping 操作。

此致、

Nick

Daniel、您好！

本周更新：我们需要固件开发人员提供更多信息和调试。 上周、固件开发人员忙于为 AM24x / AM62x / AM64x 推出 MCU+ SDK、本周他们将休假。 我将让他们和 Linux 开发人员通过电话进行沟通、以便他们可以在本周晚些时候或下周初彼此交流、并在下周提供另一个更新。

此致、

Nick

Daniel、您好！

感谢您的耐心等待。 本周、固件开发人员将最终处理该请求。 我每天都在与他们同步、以便获取更新并在可能的情况下提供支持。 尚未进行任何主要更新(过去几天、它们一直专注于在不同软件版本上获得具有不同数据包大小的详细基准)。 我将在收到前进进展的消息时或下周某个时候再次提供最新消息。

此致、

Nick

Daniel、您好！

我们正在取得良好进展！ 此问题似乎是由添加到 PRU 固件的额外错误预防代码引起的。

(更多汇编指令意味着 执行 所有汇编指令需要更长的时间。 这意味着发送以太网数据包需要更长的时间、这意味着以太网吞吐量会降低)。

开发人员找到了一种重写固件代码的方法、可以用更少的汇编指令执行相同的错误检查。 更新的固件似乎在 SDK 6.3吞吐量级别运行。 开发人员仍在本周和下周验证固件、因此这仍然是"草稿"固件。 今天、我将向您发送 Andreas PRU 固件二进制文件、供您在今天结束前进行测试。

允许测试的更改摘要  

Linux 驱动程序和内核：无需更改

PRU 固件：作为预构建的二进制文件提供。 只需替换文件系统中的现有 PRU 固件  
lib/固件/ti-pruss
(如果您希望保留原始二进制文件进行测试、请随意重命名、如"am335x-pru0-prueth-fw.elf.orig"

此致、

Nick

Daniel、您好！

我离线收到了以下反馈：

I did some tests and have some observations:
- Right after boot, the performance is still degraded (tested with iperf3).
- After some time, the performance goes to normal. Some times after less than
   a minute, sometimes after much more than that.
- It is not clear to me yet how to trigger it.

请注意、传输数据包对于 Linux ARM 内核而言非常占用资源。 如果引导后吞吐量不是那么高、则 Linux 可能仍在设置系统的其他部分。

您可以通过设置与 EVM 的多个连接并使用 TOP 来检查处理器的使用情况来进行测试。 当 TX 性能没有那么高时、Linux 内核是否会被其他进程占用？ 我在下面附上了一些示例测试设置。

示例设置1：AM437x 电路板上用于通过 NFS 加载文件系统的静态 IP 地址  

Linux PC 终端1：照常连接到/dev/ttyUSBx 连接

引导板。 电路板具有分配给 uboot 中 CPSW 端口的静态 IP 地址(例如192.168.1.140)、以及连接到 Linux PC 以太网端口192.168.2.100的 PRUETH 端口。

在 Linux 终端1上出现 EVM 登录提示后、在 Linux PC 终端2中通过 SSH 连接：
SSH root@192.168.1.140

然后使用 Linux 终端3在 Linux PC 上运行命令。

现在我们可以运行实验：
端子1：#顶部
端子3：$ iperf3 -4 -s -p 12345 -f M
终端2：# ifconfig eth1 192.168.2.140
端子2：# iperf3 -c 192.168.2.100 -p 12345-4 -f M

示例设置2：不使用 NFS  

在这种情况下、我们需要先为 CPSW 端口分配 IP 地址、然后才能连接到该端口。

Linux PC 终端1：照常连接到/dev/ttyUSBx 连接

CPSW 端口连接到 Linux PC 端口192.168.1.100、PRUETH 端口连接到 Linux PC 端口192.168.2.100。

EVM 登录提示出现后、登录并设置以太网端口：

终端1：# ifconfig eth0 192.168.1.140
终端1：# ifconfig eth1 192.168.2.140

现在、我们可以继续测试、如示例设置1中所示：

终端2：$ ssh root@192.168.1.140
端子3： $ iperf3 -4 -s -p 12345 -f M
端子1：#顶部
端子2：# iperf3 -c 192.168.2.100 -p 12345-4 -f M

此致、

Nick

您好 Nick

您说得对、有一个过程使用过多的 CPU 时间来降低性能。 完成后、性能达到预期值10.5 MB/s。

此致、Daniel

Daniel、您好！

好的、好的。 如果您在测试时遇到任何其他问题、请告知我。 开发人员应在本周结束之前完成其旁边的验证。 完成验证后、我将为 SDK 7.3和8.2公开发布 AM437x PRUETH 二进制文件、并在此处链接到它们。

此致、

Nick

您好、Nick、

你有更新吗？ 我有兴趣测试正式版本。

此致、

Daniel

Daniel、您好！

我还没有从固件开发人员那里获得更新。 我将再次与他们签入、感谢您的 Ping 操作。

此致、

Nick

您好、Nick、

你那有新消息吗？

此致、Daniel