This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM623:如何提高 Netperf (或 iperf3) CPU 利用率来提高以太网 TX/RX 带宽。

Guru**** 2537550 points
Other Parts Discussed in Thread: SK-AM62B

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1380407/am623-how-to-increase-netperf-or-iperf3-cpu-utilization-to-improve-ethernet-tx-rx-bandwidth

器件型号:AM623
主题中讨论的其他器件:SK-AM62B

工具与软件:

您好、亲爱的专家

客户的主板具有较低的 TX (客户端->服务器)以太网带宽、因此我尝试帮助他们确定根本原因。

第一步、我尝试基于软件角度来调试这个问题。

 

这是我的 Netperf 脚本、

#!/bin/bash
for i in 5
do
   netperf -H 192.168.10.99 -j -c -l 60 -p 1203 -t TCP_STREAM
     # -k DIRECTION,THROUGHPUT,MEAN_LATENCY,LOCAL_CPU_UTIL,REMOTE_CPU_UTIL,LOCAL_BYTES_SENT,REMOTE_BYTES_RECVD,LOCAL_SEND_SIZE &
   netperf -H 192.168.10.99 -j -c -l 60 -p 1203 -t TCP_MAERTS --
     # -k DIRECTION,THROUGHPUT,MEAN_LATENCY,LOCAL_CPU_UTIL,REMOTE_CPU_UTIL,LOCAL_BYTES_SENT,REMOTE_BYTES_RECVD,LOCAL_SEND_SIZE &
done

*[测试1]: 在客户主板上运行 Netperf ,结果 如下。

root@am62xx-evm:~# ./netperf-client.sh
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.99 () port 0 AF_INET : histogram : interval
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % ?      us/KB   us/KB

131072  16384  16384    60.03       862.70   28.28    -1.00    10.742  -1.000
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.99 () port 0 AF_INET : histogram : interval
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Recv     Send     Recv    Send
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % ?      us/KB   us/KB

131072  16384  16384    60.00       941.41   34.34    -1.00    11.954  -1.000

我们发现从客户端到服务器(TX)的带宽仅为862.70Gbps、本地 CPU 利用率约为28.28%

* 在 客户主板上运行 Netperf 之前转储 CPU 利用率。

00:12:28     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
00:12:29     all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
00:12:29       0    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
00:12:29       1    0.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00   99.00
00:12:29       2    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
00:12:29       3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

*  Netperf 在客户主板上运行时转储 CPU 利用率。

00:22:13     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
00:22:14     all    0.51    0.00   13.37    0.00    2.83   18.51    0.00    0.00   64.78
00:22:14       0    0.00    0.00   17.17    0.00   10.10   72.73    0.00    0.00    0.00
00:22:14       1    0.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00   99.00
00:22:14       2    2.22    0.00   26.67    0.00    1.11    0.00    0.00    0.00   70.00
00:22:14       3    0.00    0.00    9.09    0.00    0.00    0.00    0.00    0.00   90.91

*[测试2]: 在 AM62 EVB 上运行 Netperf ,结果 如下。

root@am62xx-evm:~# ./netperf-client.sh
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.99 () port 0 AF_INET : histogram : interval
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % ?      us/KB   us/KB

131072  16384  16384    60.02       934.94   42.89    -1.00    15.032  -1.000
MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.10.99 () port 0 AF_INET : histogram : interval
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Recv     Send     Recv    Send
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % ?      us/KB   us/KB

131072  16384  16384    60.00       941.45   51.28    -1.00    17.847  -1.000

我们发现 AM62 EVB 具有更好的以太网带宽性能(934~941Gbps)以及更高的 CPU 利用率(42%~51%)

*  在 EVB 上运行 Netperf 之前转储 CPU 利用率。

01:13:18     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
01:13:19     all    0.75    0.00    2.51    0.00    0.25    0.25    0.00    0.00   96.24
01:13:19       0    1.01    0.00    5.05    0.00    0.00    0.00    0.00    0.00   93.94
01:13:19       1    2.97    0.00    3.96    0.00    0.99    0.00    0.00    0.00   92.08
01:13:19       2    0.99    0.00    0.99    0.00    0.00    0.99    0.00    0.00   97.03
01:13:19       3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

*  Netperf  在 EVB 上运行时转储 CPU 利用率。

01:17:10     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
01:17:11     all    0.80    0.00   18.50    0.00    6.43   24.66    0.00    0.00   49.60
01:17:11       0    1.15    0.00   36.78    0.00    4.60    0.00    0.00    0.00   57.47
01:17:11       1    0.00    0.00    0.00    0.00   11.96   88.04    0.00    0.00    0.00
01:17:11       2    1.01    0.00    9.09    0.00    6.06   10.10    0.00    0.00   73.74
01:17:11       3    1.06    0.00   29.79    0.00    3.19    0.00    0.00    0.00   65.96

根据测试结果、我认为 CPU 利用率和性能应该是影响以太网带宽的因素之一。

我们的 EVB 对 netpref 具有更高的 CPU 利用率、因此可以在以太网上获得更好的性能。

我尝试调整"中断节奏"、但在客户板上对我来说不起作用。

较高的延迟周期会获得最差的以太网带宽、默认值"20"更好。

ethtool -C eth0 rx-usecs <delayperiod> 
ethtool -C socnet0 tx-usecs 20
ethtool -C socnet0 rx-usecs 20

我们是否有其他软件方法可以提高以太网性能?  

需要更多建议。

非常感谢

Gibbs

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Gibbs、

    在客户的电路板和 EVM 上运行 iperf3测试时、您是否看到相同的吞吐量性能?  

    我有一个建议是运行 UDP iperf3测试940Mbps 吞吐率、并检查是否报告了任何丢失的数据报(如"iperf3 -c) 客户端设备上的-b940M -L1400 -u")。 此外、在此测试期间检查 CPU 利用率、以便与您从 Netperf 获得的结果进行比较。  

    我假设您将 DUT 直接连接到单链路伙伴器件/板?

    我假设这是来自客户端设备的、您报告的 CPU 利用率是多少?

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨、Gibbs、

    感谢您分享这些详细的结果。

    我想澄清的一点是、您是否已确认从 DUT 传输到链路伙伴 PC 的传输数据包未损坏或在 PC 的接收端丢弃? 同样、是否在从链路伙伴 PC 发送的 DUT 的接收端看到任何损坏的数据包? 我只是想对此进行检查、以排除由于丢包而导致带宽较低的可能性。 可以使用"ethtool -S 进行检查 "。

    另一个问题是、如果您在 DUT 上运行 RT-Linux (preempt-RT)或常规 Linux? 如果运行 RT-Linux、有时增加 ksoftirq 和 iperf3本身的优先级可以增加吞吐量。 这更明显的是、运行"iperf -u"选项来发送 UDP 数据包、而不是使用 iperf3运行的 TCP 数据包。  

    ps -ALo psr,policy,priority,pid,tid,cputime,comm | grep ksoft --> to grep priority of ksoftirqs
    chrt -f -p <priority> <process id> ---> to change priority of process id

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Gibbs、

    感谢您分享这些详细信息。 因为我在过去几天不在办公室,所以对延迟响应表示歉意。

    根据我当前的理解、这种约~350Mbps 的低吞吐量仅显示在 DUT 上、而不显示在 EVM 上?

    此外、您能否分享您使用的 SDK 版本? 您是否使用了 TI SDK 中的 defconfig? 您从何处获得 SDK (TI.com 或主线 Linux 内核)?

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Daolin

    感谢您的答复、下面让我更新调试状态。

    (1)仅在客户的 DUT 上显示大约~350Mbps 的低吞吐量。

    (2)客户的 SDK 是: ti-processor-sdk-linux-rt-am62xx-evm-09.00.00.03

    经过几天的调试、我们找到了关键线索。

    似乎、如果您在内核中启用"config_preempt_rt"、则  TX 端的吞吐量将会较低(~350Mbps)。  

    将文件配置为附件。  

    启用 RT 时是否处于正常状态? 为什么会发生这种情况? 如何解决?

    非常感谢

    Gibbs

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨、Gibbs、

    感谢您分享您的调查结果。

    我想假设包含您共享的"CONFIG_PREPEMPT_RT=y"的配置文件是从  ti-processor-sdk-linux-rt-am62xx-evm-09.00.00.03 SDK 中提供的默认 defconfig 生成的?  

    您是否观察到  当配置在 TX 端包含"CONFIG_PREEMPT_RT"时、TI EVM 上的吞吐量低~350Mbps?  

    据我所知、启用 RT 后的吞吐量性能不会降低、至少在 TI EVM 上是如此。 下面是我在运行 ti-processor-sdk-linux-rt-am62xx-evm-的 SK-AM62B  EVM 上看到的 CPSW 吞吐量: 09.02.01.09 . 我当前没有 设置 ti-processor-sdk-linux-rt-am62xx-evm-09.00.00.03。  

    First section is when Linux Host PC is acting as client/sending TCP packets to EVM, second section is when AM64x EVM console is acting as client/sending TCP packets to Linux Host PC.
     
     
     
    // Linux Host PC console - with CPSW ethernet
    a0500327@a0500327ws:~$ iperf3 -c 172.168.1.175
    Connecting to host 172.168.1.175, port 5201
    [  5] local 172.168.1.1 port 39170 connected to 172.168.1.175 port 5201
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec   114 MBytes   953 Mbits/sec    0    467 KBytes       
    [  5]   1.00-2.00   sec   109 MBytes   911 Mbits/sec    0    694 KBytes       
    [  5]   2.00-3.00   sec   109 MBytes   912 Mbits/sec    0    740 KBytes       
    [  5]   3.00-4.00   sec   108 MBytes   902 Mbits/sec  163    687 KBytes       
    [  5]   4.00-5.00   sec   109 MBytes   912 Mbits/sec   34    542 KBytes       
    [  5]   5.00-6.00   sec   108 MBytes   902 Mbits/sec    0    588 KBytes       
    [  5]   6.00-7.00   sec   108 MBytes   902 Mbits/sec    0    625 KBytes       
    [  5]   7.00-8.00   sec   108 MBytes   902 Mbits/sec    0    645 KBytes       
    [  5]   8.00-9.00   sec   108 MBytes   902 Mbits/sec    0    653 KBytes       
    [  5]   9.00-10.00  sec   109 MBytes   912 Mbits/sec    0    658 KBytes       
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bitrate         Retr
    [  5]   0.00-10.00  sec  1.06 GBytes   911 Mbits/sec  197             sender
    [  5]   0.00-10.00  sec  1.06 GBytes   908 Mbits/sec                  receiveriperf Done.
     
    // AM64x EVM console - CPSW ethernet
    root@am64xx-evm:~# iperf3 -c 172.168.1.1
    Connecting to host 172.168.1.1, port 5201
    [  5] local 172.168.1.175 port 40270 connected to 172.168.1.1 port 5201
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec   110 MBytes   925 Mbits/sec    0    410 KBytes       
    [  5]   1.00-2.00   sec   108 MBytes   903 Mbits/sec    0    428 KBytes       
    [  5]   2.00-3.00   sec   108 MBytes   909 Mbits/sec    0    428 KBytes       
    [  5]   3.00-4.00   sec   108 MBytes   905 Mbits/sec    0    428 KBytes       
    [  5]   4.00-5.00   sec   110 MBytes   926 Mbits/sec    0    428 KBytes       
    [  5]   5.00-6.00   sec   112 MBytes   939 Mbits/sec    0    428 KBytes       
    [  5]   6.00-7.00   sec   112 MBytes   935 Mbits/sec    0    428 KBytes       
    [  5]   7.00-8.00   sec   111 MBytes   934 Mbits/sec    0    484 KBytes       
    [  5]   8.00-9.00   sec   111 MBytes   933 Mbits/sec    0    484 KBytes       
    [  5]   9.00-10.00  sec   112 MBytes   944 Mbits/sec    0    625 KBytes       
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bitrate         Retr
    [  5]   0.00-10.00  sec  1.08 GBytes   925 Mbits/sec    0             sender
    [  5]   0.00-10.04  sec  1.07 GBytes   919 Mbits/sec                  receiveriperf Done.
    

    是否可以尝试  ti-processor-sdk-linux-rt-am62xx-evm- 09.02.01.09  在客户的 DUT 上、只是为了看看较新的 SDK 是否会表现出性能方面的改进?

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Daolin

    感谢您的评论。

    几个问题和状态更新

    (1)我发现您的测试是单向测试、而不是双向测试。 在 DUT 上可以满足单向要求、问题仅发生在 双向上。 命令参数

     iperf3 -c 192.168.10.99 -i 4 -t 20 -b 0 --bidir

    (2)分享客户反馈中的一些测试结果。 由于授权问题、我会将此数据发送给您的邮件。 "RT 启用"问题似乎仅发生在 DUT 上、而不发生在 EVM 上。

    Gibbs

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Gibbs、

    感谢您分享客户的测试结果、我将在电子邮件中针对这些结果提出几个问题/评论。

    您在 之前的回复中提到了"DUT OS : Regular Linux without RT",但在最近的回复中提到了"(2) Customer's SDK 是: ti-processor-sdk-linux- rt -am62xx-evm-09.00.00.03"。 为了澄清一点、目标操作系统是 RT-Linux 而非"常规"Linux (无 preempt_RT 配置)? 客户的用例是什么(是否有特殊原因需要 RT-Linux)?

    是的、我之前展示的结果是 RX 和 TX 路径上的单向测试(从 EVM 的角度)、这些测试是我几个月前运行的、所以我没有现成的双向测试结果可供分享)。

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Daolin

    问题应该得到解决。

    这可能是特定 A 内核的 IRQ 过载。 尝试  在 iperf 运行时检查 IRQ 状态是否为8000000.ethernet-tx0和8000000.ethernet。

    请参考此线程、尝试修改 IRQ 和 A 核心服务映射。

    (1) https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1342656/sk-am62a-lp-frame-drop-often-happens-on-am62ax-platform/5161884?tisearch=e2e-sitesearch&keymatch=irqbalance#5161884

    (2) https://blog.csdn.net/ye1223/article/details/85050498

    Gibbs

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Gibbs、

    感谢您分享此更新。 只是为了澄清此问题的解决方案、请确保两个 IRQ (8000000.Ethernet-tx0和8000000.ethernet)在同一 A53内核上运行、根据您在电子邮件中的陈述、这似乎是 EVM 上默认 SDK 的默认设置、但不会导致您之前指示的吞吐量较低?

    "根本原因:

    它们尝试将"8000000.ethernet-tx0"和"8000000.ethernet" IRQ 分离到不同的内核

    EVM 上的默认 SDK 已经独立了 IRQ (117/207)、但我不确定它们为什么使用相同的内核。"

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Daolin

    问题1:  

    虽然 "8000000.Ethernet-tx0"和"8000000.ethernet"使用不同的 IRQ、一个是117、另一个是207。 我是否错过了理解?

    问题2:

    如何知道 IRQ (8000000.Ethernet-tx0和8000000.ethernet)在同一个内核上工作? 以及如何 将 IRQ 分离到不同的内核?

    非常感谢

    Gibbs

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Gibbs、

    对于这些问题、我需要与开发团队和同事核实。 我希望明天能得到答案。

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    嗨、Gibbs、

    此外、在与同事交谈后、我们希望仔细检查以下事项:

    您能解释一下下面的问题吗? 您/客户是否手动启用了 CONFIG_PREMPT_RT=y? 我们之所以提出这个问题、是因为应该已经使用  ti-processor-sdk-linux-设置 CONFIG_PREMPT_RT=y 了 rt -am62xx-evm-09.00.00.03 SDK。 此 SDK 中提供的 defconfig 已经过调优、因此、如果超出它的配置、更改配置可能会带来较差的性能。

    [quote userid="576780" url="~/support/processors-group/processors/f/processors-forum/1380407/am623-how-to-increase-netperf-or-iperf3-cpu-utilization-to-improve-ethernet-tx-rx-bandwidth/5301353 #5301353(2001)我假设包含您共享的"config_preempt_rt=y"的配置文件由 ti-processor-sdk-linux-rt-am62xx-evm-09.00.00.03  SDK 中提供的默认 defconfig 生成?  [报价]

    通常、我们不会将 IRQ 更改为特定内核来提高吞吐量性能、这就是我们想要再次检查 defconfig 的原因。

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Daolin

    1) "config_preempt_rt=y"不是根本原因、因为它们尝试在 DUT 和使用内核上移植"ti-processor-sdk-linux-am62xx-evm-09.00.00.03-linux-x86-Install.bin"和"ti-processor-sdk-linux-rt-am62xx-evm-09.00.00.03-linux-config-Install.bin"内核、仍然会发生默认问题。 无论是否启用 RT、问题仍然存在

    2) 2)我尝试  在 EVB 上使用"ti-processor-sdk-linux-am62xx-evm-09.00.00.03-linux-x86-Install.bin"和"processor-sdk-linux-rt-am62xx-evm-09.00.03-linux-x86-Install.bin"、并使用默认内核设置和 rootfs、不会发生问题。

    2)因为项目1&2的结论,他们尝试调试 rootfs . 我和 VARiS,Pekka 分享 IRQ 相关的建议,我相信他们有一些想法,所以他们尝试研究 IRQ。

    谢谢

    Gibbs

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Gibbs、

    感谢您阐明 CONFIG_PREMPT_RT 配置。 我已经和 CPSW 以太网开发人员说过、这里是反馈:

    [报价 userid="533255" url="~/support/processors-group/processors/f/processors-forum/1380407/am623-how-to-increase-netperf-or-iperf3-cpu-utilization-to-improve-ethernet-tx-rx-bandwidth/5318402 #5318402"]

    问题1:  

    虽然 "8000000.Ethernet-tx0"和"8000000.ethernet"使用不同的 IRQ、一个是117、另一个是207。 我是否错过了理解?

    [报价]

    这确实是两个独立的 IRQ、您的理解是正确的。

    • 8000000.Ethernet-tx0是以太网 发送 IRQ (软件将数据包放置在 DMA 通道上、以便传递到主机端口)
    • 8000000.Ethernet 是以太网 接收 IRQ (软件从主机端口接收数据包)
    [报价 userid="533255" url="~/support/processors-group/processors/f/processors-forum/1380407/am623-how-to-increase-netperf-or-iperf3-cpu-utilization-to-improve-ethernet-tx-rx-bandwidth/5318402 #5318402"]

    问题2:

    如何知道 IRQ (8000000.Ethernet-tx0和8000000.ethernet)在同一个内核上工作? 以及如何 将 IRQ 分离到不同的内核?

    [报价]

    这个问题有点令人困惑、因为您在/proc/interrupts.中的屏幕截图结果已指示了两个以太网 IRQ 在哪个内核上运行 对于该特定的屏幕截图情况、 内核0上有14个8000000.Ethernet-tx0中断、内核2上有419个8000000.Ethernet-tx0中断、内核0上有6个8000000.Ethernet 中断、内核1上有149个8000000.Ethernet 中断。

    每个 IRQ 运行在哪个内核上通常取决于 irqbalance 守护程序、该守护程序试图使所有内核上的中断数量保持相等。 如果希望完全控制中断的 CPU 关联性、则必须禁用 irqbalance 守护程序并将中断屏蔽到不同的内核。

    [报价用户 id="576780" url="~/support/processors-group/processors/f/processors-forum/1380407/am623-how-to-increase-netperf-or-iperf3-cpu-utilization-to-improve-ethernet-tx-rx-bandwidth/5316888 #5316888"]

    "根本原因:

    它们尝试将"8000000.ethernet-tx0"和"8000000.ethernet" IRQ 分离到不同的内核

    EVM 上的默认 SDK 已经独立了 IRQ (117/207)、但我不确定它们为什么使用相同的内核。"

    [报价]

    我之前想澄清一下我对您所做回应的理解、即吞吐量较低的根本原因。 您是否不确定为什么客户的平台将这两个 IRQ 设置为在同一内核上运行、以及当它们在同一内核上时、吞吐率会更低?

    您能否检查他们的根文件系统中是否有 irqbalance 守护程序运行? 怀疑是否禁用了 irqbalance、这或许就是两个 IRQ 在同一个内核上运行的原因。

    -道林