[参考译文] J784S4XEVM：R5f 和 C71 内核上的以太网固件的性能问题（1Gb/10Gb 配置）

您好、

我们还使用 SDK 11 进行了测试、而 R5f 内核略有改进 ~218Mbit/s 、结果仍然远低于预期 1Gbps 使用 A72 内核时的性能。

请参阅以下内容、了解使用 PDK 中的 TI SDK ENET 示例时的性能数字。

https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j784s4/11_00_00_06/exports/docs/pdk_j784s4_11_00_00_21/docs/datasheet/j784s4/datasheet_j784s4.html#cpsw-9g

是否需要任何额外的配置步骤或代码更改来实现更高的吞吐量（1GbE 接近 1Gbps、10GbE 接近线速）？

以上是 使用 TI 发布的传统 SDK 示例所实现的最大数量。

您可以选中以下选项以改进性能数字。

1. 从 ETHFW 禁用调试 UART 打印。
2. 从“pdk/packages/ti/drv/enet/examples/utils/enet_appmemutils.c"（“（默认（默认具有 128 个描述符）配置一个更大的 no.of 描述符和数据缓冲区
3. 调优计时器的周期以处理 Tx 和 Rx 数据包（默认为 1ms）。
   
4. 调节 lwip 选项（用于 TCP 和 UDP 的栈）

此致、
Sudheer

您好、

以上是我们 使用 TI 发布的传统 SDK 示例实现的最大数量。

好的、但为什么我们使用 C7 和 10Gb 配置时的统计数据/比特率相同？ 我们是否需要更改 C7 的一些 TX 通道/UDMA 配置以获得更好的结果？

您可以查看以下选项来提高性能数字。

 1、2 点和 3 点没有改善。

调整 lwip 选项（用于 TCP 和 UDP 的堆栈）

您的意思是什么？

此致、

Abdelaziz

您好、

[引述 userid=“609281" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1526777/j784s4xevm-performance-issue-with-ethernet-firmware-on-r5f-and-c71-cores-1gb-10gb-configurations/5876425 #5876425“]

Doredla Sudheer Kumar 说:

调节 lwip 选项（用于 TCP 和 UDP 的栈）

您的意思是什么？

[/报价]

可通过增加 存储器池来进行检查。  
调整 TCP 线程优先级。

[引述 userid=“609281" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1526777/j784s4xevm-performance-issue-with-ethernet-firmware-on-r5f-and-c71-cores-1gb-10gb-configurations/5876425 #5876425“]

Doredla Sudheer Kumar 说:

以上是 使用 TI 发布的传统 SDK 示例所实现的最大数量。

好的、但为什么我们使用 C7 和 10Gb 配置时的统计数据/比特率相同？ 我们是否需要更改 C7 的一些 TX 通道/UDMA 配置以获得更好的结果？

[/报价]

因为我们不会将任何内容卸载到硬件上。
结果可能因内核时钟而异。

此致、
Sudheer

遗憾的是、上述选项均未导致任何性能改进。 您还有其他我们可以尝试的建议吗？

此外、您能否确认 Linux 实现是否基于中断、而 ETHFW/FreeRTOS 实现是否依赖于轮询？ 如果是、这种差异是否是问题的潜在根本原因、并解释比特率的显著差异？

您好、

另外、您能否确认 Linux 实现是否基于中断、而 ETHFW/FreeRTOS 实现是否依赖于轮询？ 如果是、这种差异是否可能成为问题的根本原因并解释比特率的显著差异？

不完全相同、Linux 在  SMP 中的 A72 内核上运行。  
此外、A72 比 R5F 内核强大、还具有高速缓存一致性支持。

此致、
Sudheer

尊敬的 Doredla：

感谢您的答复。

“那你呢?

不幸的是、上面提到的任何选项都没有导致任何性能改进。 您还有其他建议可以尝试吗？

我们投入了大量精力、将以太网固件客户端迁移到 C7 内核并设置 10Gbps 配置。 令人失望的是、现在性能远低于预期—我们在 C7 上的速度仅达到 187 Mbps。

此致、

Abdelaziz

您好、

[报价 userid=“609281" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1526777/j784s4xevm-performance-issue-with-ethernet-firmware-on-r5f-and-c71-cores-1gb-10gb-configurations/5888502 #5888502“]

Abdelaziz Belhareth 说：

遗憾的是、上述选项均未导致任何性能改进。 您还有其他我们可以尝试的建议吗？

我们投入了大量精力、将以太网固件客户端迁移到 C7 内核并设置 10Gbps 配置。 令人失望的是、现在性能远低于预期—我们在 C7 上的速度仅达到 187 Mbps。

[/报价]

使用 11.0 SDK 时、您可能会看到上面分享的稍高的数字。
https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j784s4/11_00_00_06/exports/docs/ethfw/docs/datasheet/index.html
https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-j784s4/11_00_00_06/exports/docs/pdk_j784s4_11_00_00_21/docs/datasheet/j784s4/datasheet_j784s4.html#cpsw-9g

我们可能需要优化以太网数据和 lwip 选项的处理、以进一步提高吞吐量、从现在开始、我们是使用 TI SDK 的吞吐量。

此致、
Sudheer

你（们）好

使用 11.0 SDK 时、您可能会看到上面共享的数字稍高一些。

如说明中所述、使用 SDK 10 和 11 将以太网固件客户端迁移到 C7 目前未成功。
我们正在单独跟踪这个问题、遗憾的是、这个问题仍未解决。

此外，即使迁移问题得到解决，到目前为止观察到的性能改进仅为几兆字节，这不足以满足我们的要求 — 我们需要良好的 10Gbps 吞吐量。

此外、我们还有一个有关 RX 数据包处理机制的问题。 字节 、任务 Lwip2enet_rxPacketTask() 负责处理 RX 数据包。 此任务等待应该由 UDMA 事件 ISR Lwip2enet_notifyRxPackets () 发布的信标。
但是、我们注意到、出于某种原因、似乎没有按预期调用 ISR。 而是使用另一个操作系统计时器回调 Lwip2enet_timerCb (),每 1ms 发布一次信标。

您能解释一下为什么需要进行该计时器回调吗？ UDMA ISR 是否未按预期运行、引入此回调是作为权变措施吗？

了解此处的基本原理将有助于我们进行大量调试并可能优化性能。

此致、

Abdelaziz

您好、

此外、即使迁移问题得到解决、到目前为止观察到的性能改进只有几兆字节、这不足以满足我们的要求—我们需要良好的 10Gbps 吞吐量。

 IP 本身存在一个问题、DMA 无法推送 10G 速率。
目前正在内部调查、以解决此问题。

此外、我们还有一个关于 RX 数据包处理机制的问题。 字节 、任务 Lwip2enet_rxPacketTask() 负责处理 RX 数据包。 此任务等待应该由 UDMA 事件 ISR Lwip2enet_notifyRxPackets () 发布的信标。
但是、我们注意到、出于某种原因、似乎没有按预期调用 ISR。 而是使用另一个操作系统计时器回调 Lwip2enet_timerCb (),每 1ms 发布一次信标。

通过这两种方法都是 ISR 和计时器回调实现的软件。 在测试吞吐量时、更多的中断被触发到内核、从而导致 CPU 承受大量负载。
因此、在最新的 SDK 版本中、我们默认禁用了 ISR 模型、并启用了计时器回调方法。

这背后的理念是拥有与 Linux 驱动程序类似的调度机制。

据我所知、我们需要优化 LWIP 堆栈和选项、以获得当前无法获得的吞吐量、并对任何与处理相关的瓶子颈项进行排序。

此致、
Sudheer

尊敬的 Doredla：

 IP 本身存在一个问题、DMA 无法推送 10G 速率。
目前正在内部调查以解决此问题。

该 线程中提到的问题 专门与将默认以太网固件客户端（配置为 1Gb）从 R5 内核 (MCU2_1) 迁移到 C7 DSP 失败有关。 我相信您提到的是另一个问题、对吧？

如果是这种情况、那么只需澄清一下：即使在 SDK 9 中、我们成功地将 ETHFW 客户端迁移到 C7 内核、由于您前面提到的 IP 级别限制、我们仍然无法实现 10G 吞吐量、这是正确的吗？

S/W 通过 ISR 和计时器回调两种方法实现。 在测试吞吐量时、有更多的中断触发到内核、从而导致 CPU 承受很大的负载。

这对于 R5 客户端内核来说是可以理解的、但为什么我们看到  C7 DSP 客户端具有相同的吞吐量、这明显比 R5 更强大？

根据我的理解、我们需要优化 LWIP 堆栈和选项、以获得当前不可用的吞吐量、并对任何与处理相关的瓶子颈项进行排序

由于我们目前被阻止、您能告诉我可以修改和测试的相关代码区域吗？

您好、

[引述 userid=“609281" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1526777/j784s4xevm-performance-issue-with-ethernet-firmware-on-r5f-and-c71-cores-1gb-10gb-configurations/5898515 #5898515“]

Doredla Sudheer Kumar 说:

 IP 本身存在一个问题、DMA 无法推送 10G 速率。
目前正在内部调查、以解决此问题。

该 线程中提到的问题 专门与将默认以太网固件客户端（配置为 1Gb）从 R5 内核 (MCU2_1) 迁移到 C7 DSP 失败有关。 我相信您提到的是另一个问题、对吧？

[/报价]

是、上文与使用最新 TI SDK 的 C7x 客户端使能无关。

如果是这种情况、那么就澄清一下：即使在 SDK 9 中、我们成功地将 ETHFW 客户端迁移到 C7 内核、由于您之前提到的 IP 级别限制、我们仍然不会实现 10G 吞吐量、这是正确的吗？

是的、IP 级别限制为达到 10G。

[引述 userid=“609281" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1526777/j784s4xevm-performance-issue-with-ethernet-firmware-on-r5f-and-c71-cores-1gb-10gb-configurations/5898515 #5898515“]

Doredla Sudheer Kumar 说:

通过这两种方法都是 ISR 和计时器回调实现的软件。 在测试吞吐量时、更多的中断被触发到内核、从而导致 CPU 承受大量负载。

这对于 R5 客户端内核来说是可以理解的、但为什么我们看到  C7 DSP 客户端具有相同的吞吐量、这明显比 R5 更强大？

[/报价]

R5F 的静态代码库、LWIP 栈和选项相同。

[引述 userid=“609281" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1526777/j784s4xevm-performance-issue-with-ethernet-firmware-on-r5f-and-c71-cores-1gb-10gb-configurations/5898515 #5898515“]

Doredla Sudheer Kumar 说:

据我所知、我们需要优化 LWIP 堆栈和选项、以获得当前无法获得的吞吐量、并对任何与处理相关的瓶子颈项进行排序

由于我们目前被阻止、您能告诉我可以修改和测试的相关代码区域吗？

[/报价]

这仍然是 TI 需要研究的工作领域。 我们还没有现成的解决方案。

 我可以建议的一点是、您可以通过使用超高容量 UDMA 通道而非客户端内核中的正常 DMA 通道进行传输来进行检查。

此致、
Sudheer

尊敬的 Doredla：

感谢您的答复。

 我可以建议的一件事是、您可以使用超高容量 UDMA 通道进行检查、而不是使用客户端内核中的正常 DMA 通道进行传输。

目前、在我们的 C7 ETHFW 客户端内核上、UDMA ISRLwip2Enet_notifyRxPackets() () 从未被触发。 这表明 C7 内核的当前 UDMA 配置可能存在问题、在此阶段、我们只是从 MCU2_1 客户端复制了配置。

您能否确认此方法是否有效？ 如果没有、您能指导我如何为 C7 客户端正确配置 UDMA 吗？

我认为正确触发 ISR 会显著提高 C7 内核的吞吐量。

您好、

目前、在我们的 C7 ETHFW 客户端内核上、UDMA ISRLwip2Enet_notifyRxPackets() () 从未被触发。 这表明 C7 内核的当前 UDMA 配置可能存在问题、在此阶段、我们只是从 MCU2_1 客户端复制了配置。

默认情况下、中断模式被禁用、仅轮询被启用。
因此、 在轮询模式下不会调用 Lwip2enet_notifyRxPackets。

如果 要 启用 ISR、请设置  disableEvent AS BFALSE  从 ETHFW 客户端中的“LwipifEnetAppCb_getHandle"API 启动“ 启动。  

此致、
Sudheer

您好、

感谢您的答复。

如前所述、由于 CPU 负载增加、启用 ISR 会导致吞吐量下降、即使在 C7 内核上也是如此。

您能给我指一下代码中设置客户端 DMA 配置的部分、特别是源地址和目标地址、以及分配给数据复制的内存。

是的、存在达到 10G

的 IP 级别限制

您能否 解释一下 限制的根本原因是什么？ 您还使用哪种应用程序/测试了 10G 配置？

尊敬的 Doredla：

感谢您的答复。

您能 解释一下 限制的根本原因是什么吗？ 您还使用哪个应用程序/测试了 10G 配置？

“那你呢?

您好、

Abdelaziz Belhareth 说：

您能否 解释一下 限制的根本原因是什么？ 您还使用哪种应用程序/测试了 10G 配置？

“那你呢?

[/报价]

我们尚未测试 R5F 内核提供的 10G 吞吐量。 我们仅在 A72 内核上使用 Linux 进行了测试、 采用标准 Linux 网络栈时可达到~3.3Gbps。

此致、
Sudheer

尊敬的 Doredla：

我当前正在尝试为 C7 ETHFW 客户端配置硬件计时器、而不是 OS_TIMER。 我正在使用 TimerP_create() 函数、该函数返回成功状态。 但是、绝不会触发 ISR 回调。

有趣的是、当我在 MCU2_0（ETHFW 服务器）上测试相同的设置时、回调函数按预期工作。 我已经仔细检查了 EventID、intNum 和 timerBaseAddress、它们看起来是正确的：[EventID = 1252 、intNum = 18、baseAddr = 0x2440000 (Timer4)]

此外,TimerP_getCount () 显示计时器计数器正在递增,这表明计时器正在正常运行。

您是否知道为什么 ISR 可能不会在 C7 内核上触发？ 我的目标是评估使用周期短于 OS_TIMER 的硬件计时器是否有助于提高吞吐量。

感谢任何指导！

此致、

Abdelaziz

您好、

特别地、当我在 MCU2_0（ETHFW 服务器）上测试相同的设置时、回调函数按预期工作。 我已经仔细检查了 EventID、intNum 和 timerBaseAddress、它们看起来是正确的：[EventID = 1252 、intNum = 18、baseAddr = 0x2440000 (Timer4)]

根据 SDK 配置、事件编号和中断编号是正确的。

您能否检查任何其他内核是否使用同一计时器？ 如果您需要与计时器相关的任何其他支持、请创建新主题。

此致、
Sudheer

您好、

我为此主题创建了一个新主题。

你对这个想法有什么想法? 您认为这有助于提高吞吐量吗？

此致、
Abdelaziz

您好、

Sudheer,你对这个想法有什么想法? 您认为这有助于提高吞吐量吗？

如果您有大量匹配的缓冲区和时间间隔以利用/容纳接收到的数据包、这将略有改善。

此致、
Sudheer

您好、

硬件计时器现在正常工作。 其目的是避免启动操作系统计时器、而是完全依赖硬件计时器。 为此、我将 Lwip2enet_timerCb () 函数中的代码复制到硬件计时器的 ISR 回调中。

但是、当调用 SemaphoreP_post()（以及 SemaphoreP_postFromISR ()) 时、代码会卡住。 作为一种解决方法、我尝试将 Lwip2enet_rxPacketTask () 的内容直接移动到 ISR 回调中、但随后在调用 TCPIP_inpkt ()(ti/transport/lwip/lwip-stack/lwip/api/tcpip.c src) 时代码挂起。 不幸的是、我无法确定它卡住的确切线。

您是否知道导致此问题的原因？ 在 ISR 上下文中执行此代码是否安全、甚至是否可能、或者这与 ISR 执行基本不兼容？

此致、

Abdelaziz

您好、

[引用 userid=“609281" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1526777/j784s4xevm-performance-issue-with-ethernet-firmware-on-r5f-and-c71-cores-1gb-10gb-configurations/5947695

但是、当调用 SemaphoreP_post()（以及 SemaphoreP_postFromISR ()) 时、代码会卡住。 作为一种解决方法、我尝试将 Lwip2enet_rxPacketTask () 的内容直接移动到 ISR 回调中、但随后在调用 TCPIP_inpkt ()(ti/transport/lwip/lwip-stack/lwip/api/tcpip.c src) 时代码挂起。 不幸的是、我无法确定它卡住的确切线。

[/报价]

请参阅 TI 基于 ISR 的实现、我们在这里调用使用 Rx 流信息寄存的调用回调、以调用信标 POST。

[引用 userid=“609281" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1526777/j784s4xevm-performance-issue-with-ethernet-firmware-on-r5f-and-c71-cores-1gb-10gb-configurations/5947695

在 ISR 上下文中执行此代码是否安全、甚至是否可能、或者这与 ISR 执行基本不兼容？

[/报价]

不建议在 ISR 中处理所有数据。 请使用具有正确流详细信息的信标发布、并利用 Rx 任务函数。

此致、
Sudheer