[参考译文] PROCESSOR-SDK-AM64X：使用数据包 HSR 卸载解决方案进行转发时、会发生数据包丢失

您好、Tianyi、

感谢您提醒我注意这一点。 我还没有在公开发行 09.02.01.10上进行测试,但今天会这样做,并在星期一回到你.  

-道林

最新动态：

我使用与您所示相同的命令测试了基本 ping 和 iperf3、但我看不到任何数据包丢失。 请参阅以下内容以了解结果。 运行这些测试时使用的是您之前共享的网络禁用命令(另一个线程)。

EVM1 (192.168.1.10) eth1 eth2  EVM2 (192.168.1.30) eth1 eth2  EVM3 (192.168.1.50) eth1 eth2 EVM1  (断开 EVM3与 EVM1之间的电缆)

EVM1：

root@am64xx-evm:~# iperf3 -c 192.168.1.50 -t40 -b20M -l400 -u
Connecting to host 192.168.1.50, port 5201
[  5] local 192.168.1.10 port 37642 connected to 192.168.1.50 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  2.38 MBytes  20.0 Mbits/sec  6245  
[  5]   1.00-2.00   sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]   2.00-3.00   sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]   3.00-4.00   sec  2.38 MBytes  20.0 Mbits/sec  6251  
[  5]   4.00-5.00   sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]   5.00-6.00   sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  253.923246] icssg-prueth icssg1-eth eth2: Link is Down
[  5]   6.00-7.00   sec  2.38 MBytes  20.0 Mbits/sec  6249  
[  5]   7.00-8.00   sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]   8.00-9.00   sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]   9.00-10.00  sec  2.38 MBytes  20.0 Mbits/sec  6251  
[  5]  10.00-11.00  sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]  11.00-12.00  sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]  12.00-13.00  sec  2.38 MBytes  20.0 Mbits/sec  6249  
[  5]  13.00-14.00  sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]  14.00-15.00  sec  2.38 MBytes  20.0 Mbits/sec  6251  
[  5]  15.00-16.00  sec  2.38 MBytes  20.0 Mbits/sec  6249  
^C[  5]  16.00-16.71  sec  1.70 MBytes  20.0 Mbits/sec  4445  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-16.71  sec  39.8 MBytes  20.0 Mbits/sec  0.000 ms  0/104440 (0%)  sender
[  5]   0.00-16.71  sec  0.00 Bytes  0.00 bits/sec  0.000 ms  0/0 (0%)  receiver
iperf3: interrupt - the client has terminated

EVM3：

root@am64xx-evm:~# iperf3 -s -B 192.168.1.50                                                                                                                                                   
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.1.10, port 51750
[  5] local 192.168.1.50 port 5201 connected to 192.168.1.10 port 37642
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  2.38 MBytes  20.0 Mbits/sec  0.006 ms  0/6245 (0%)  
[  5]   1.00-2.00   sec  2.38 MBytes  20.0 Mbits/sec  0.006 ms  0/6250 (0%)  
[  5]   2.00-3.00   sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  0/6250 (0%)  
[  5]   3.00-4.00   sec  2.38 MBytes  20.0 Mbits/sec  0.010 ms  0/6251 (0%)  
[  5]   4.00-5.00   sec  2.38 MBytes  20.0 Mbits/sec  0.035 ms  0/6250 (0%)  
[  181.283935] icssg-prueth icssg1-eth eth1: Link is Down
[  5]   5.00-6.00   sec  2.38 MBytes  20.0 Mbits/sec  0.005 ms  0/6250 (0%)  
[  5]   6.00-7.00   sec  2.38 MBytes  20.0 Mbits/sec  0.006 ms  0/6249 (0%)  
[  5]   7.00-8.00   sec  2.38 MBytes  20.0 Mbits/sec  0.008 ms  0/6250 (0%)  
[  5]   8.00-9.00   sec  2.38 MBytes  20.0 Mbits/sec  0.006 ms  0/6250 (0%)  
[  5]   9.00-10.00  sec  2.38 MBytes  20.0 Mbits/sec  0.005 ms  0/6251 (0%)  
[  5]  10.00-11.00  sec  2.38 MBytes  20.0 Mbits/sec  0.008 ms  0/6250 (0%)  
[  5]  11.00-12.00  sec  2.38 MBytes  20.0 Mbits/sec  0.005 ms  0/6250 (0%)  
[  5]  12.00-13.00  sec  2.38 MBytes  20.0 Mbits/sec  0.008 ms  0/6249 (0%)  
[  5]  13.00-14.00  sec  2.38 MBytes  20.0 Mbits/sec  0.007 ms  0/6250 (0%)  
[  5]  14.00-15.00  sec  2.38 MBytes  20.0 Mbits/sec  0.004 ms  0/6251 (0%)  
[  5]  15.00-16.00  sec  2.38 MBytes  20.0 Mbits/sec  0.008 ms  0/6249 (0%)  
[  5]  15.00-16.00  sec  2.38 MBytes  20.0 Mbits/sec  0.008 ms  0/6249 (0%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-16.00  sec  39.8 MBytes  20.9 Mbits/sec  0.005 ms  0/104440 (0%)  receiver
iperf3: the client has terminated
-----------------------------------------------------------
Server listening on 5201 (test #2)
-----------------------------------------------------------
^Ciperf3: interrupt - the server has terminated
root@am64xx-evm:~# dmesg | grep -i dual
[    8.435610] icssg-prueth icssg1-eth: TI PRU ethernet driver initialized: dual EMAC mode
root@am64xx-evm:~# 

网络禁用命令：

systemctl disable dhcpcd.service
systemctl disable NetworkManager.service
systemctl disable systemd-resolved.service
systemctl disable systemd-networkd.service
sync
reboot

由于我无法重现此问题、您能否共享设置 HSR 卸载时生成的整个控制台日志？ ping 还会导致数据包丢失？

-道林

尊敬的 Daolin：

感谢您发送编修。

似乎是您共享的测试、您未断开 电缆 C 相关链接 EVM3 (192.168.1.50) eth1 <->eth2 EVM1之间  

您能确认吗？ 如果是、您是否可以通过断开电缆 C 来重新执行测试？

最终设置应如下所示：

在我们这边、我们用 TI 最新的映像替换了 EVM2映像或(DUT 映像)。 我们发现数据包丢失了!

下一步是用 TI 最新的映像替换 EVM1和 EVM3映像、并进行相同的测试！

Tianyi

您好、Tianyi、

我之前的回复结果实际上是 EVM1和 EVM3之间的电缆断开(很抱歉、我之前没有明确说明)。

但我之前的响应在 EVM1-EVM3电缆断开时的结果相同  性能  iperf3测试。 我记得当我断开 EVM1-EVM3时  。  iperf3测试,我也没有看到任何数据包丢失,但我可以在今天晚些时候与大家分享结果。

您是否已检查过此封包丢失发生在测试板1或测试板3作为中间板/DUT？ 这只是为了确保当前 DUT 板上不会出现此问题。

我~iperf3服务器报告的传输大小和比特率是 iperf3客户端报告的大小的一半。 在仅两个器件之间测试 iperf3时、您是否看到相同的结果？ 也就是说、DUT 仅连接到另一个测试板、一个是 iperf3客户端、另一个是 iperf3服务器、然后查看是否还在 iperf3服务器上看到~一半的传输大小/比特率。

-道林

EVM1-EVM3电缆断开连接的结果 。 iperf3测试。 这个问题在我看来仍然无法重现

EVM1：

root@am64xx-evm:~# iperf3 -c 192.168.1.50 -t40 -b20M -l400 -u                                                                                                                                        
Connecting to host 192.168.1.50, port 5201
[  5] local 192.168.1.10 port 49196 connected to 192.168.1.50 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  2.37 MBytes  19.9 Mbits/sec  6223  
[  5]   1.00-2.00   sec  2.39 MBytes  20.1 Mbits/sec  6273  
[  5]   2.00-3.00   sec  2.38 MBytes  20.0 Mbits/sec  6249  
[  5]   3.00-4.00   sec  2.38 MBytes  20.0 Mbits/sec  6251  
[  5]   4.00-5.00   sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]   5.00-6.00   sec  2.38 MBytes  20.0 Mbits/sec  6249  
[  5]   6.00-7.00   sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]   7.00-8.00   sec  2.38 MBytes  20.0 Mbits/sec  6251  
[  5]   8.00-9.00   sec  2.38 MBytes  20.0 Mbits/sec  6249  
[  5]   9.00-10.00  sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]  10.00-11.00  sec  2.38 MBytes  20.0 Mbits/sec  6251  
[  5]  11.00-12.00  sec  2.38 MBytes  20.0 Mbits/sec  6250  
[  5]  12.00-13.00  sec  2.38 MBytes  20.0 Mbits/sec  6249  
^C[  5]  13.00-13.29  sec   720 KBytes  20.0 Mbits/sec  1844  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-13.29  sec  31.7 MBytes  20.0 Mbits/sec  0.000 ms  0/83089 (0%)  sender
[  5]   0.00-13.29  sec  0.00 Bytes  0.00 bits/sec  0.000 ms  0/0 (0%)  receiver
iperf3: interrupt - the client has terminated

EVM3：

root@am64xx-evm:~# iperf3 -s -B 192.168.1.50                                                                                                                                                         
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.1.10, port 34334
[  5] local 192.168.1.50 port 5201 connected to 192.168.1.10 port 49196
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  2.37 MBytes  19.9 Mbits/sec  0.083 ms  0/6223 (0%)  
[  5]   1.00-2.00   sec  2.39 MBytes  20.1 Mbits/sec  0.005 ms  0/6273 (0%)  
[  5]   2.00-3.00   sec  2.38 MBytes  20.0 Mbits/sec  0.007 ms  0/6249 (0%)  
[  5]   3.00-4.00   sec  2.38 MBytes  20.0 Mbits/sec  0.005 ms  0/6251 (0%)  
[  5]   4.00-5.00   sec  2.38 MBytes  20.0 Mbits/sec  0.005 ms  0/6250 (0%)  
[  5]   5.00-6.00   sec  2.38 MBytes  20.0 Mbits/sec  0.008 ms  0/6249 (0%)  
[  5]   6.00-7.00   sec  2.38 MBytes  20.0 Mbits/sec  0.007 ms  0/6250 (0%)  
[  5]   7.00-8.00   sec  2.38 MBytes  20.0 Mbits/sec  0.012 ms  0/6251 (0%)  
[  5]   8.00-9.00   sec  2.38 MBytes  20.0 Mbits/sec  0.007 ms  0/6249 (0%)  
[  5]   9.00-10.00  sec  2.38 MBytes  20.0 Mbits/sec  0.141 ms  0/6250 (0%)  
[  5]  10.00-11.00  sec  2.38 MBytes  20.0 Mbits/sec  0.006 ms  0/6251 (0%)  
[  5]  11.00-12.00  sec  2.38 MBytes  20.0 Mbits/sec  0.005 ms  0/6250 (0%)  
[  5]  12.00-13.00  sec  2.38 MBytes  20.0 Mbits/sec  0.006 ms  0/6249 (0%)  
[  5]  12.00-13.00  sec  2.38 MBytes  20.0 Mbits/sec  0.006 ms  0/6249 (0%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-13.00  sec  31.7 MBytes  20.5 Mbits/sec  0.006 ms  0/83089 (0%)  receiver
iperf3: the client has terminated
-----------------------------------------------------------
Server listening on 5201 (test #2)
-----------------------------------------------------------
^Ciperf3: interrupt - the server has terminated

EVM2：

hsr-tag-ins-offload: on
hsr-tag-rm-offload: on
hsr-fwd-offload: on
hsr-dup-offload: on
[   87.438457] icssg-prueth icssg1-eth: Enabling HSR offload mode
[   89.490640] remoteproc remoteproc12: powering up 300b4000.pru
[   89.495183] remoteproc remoteproc12: Booting fw image ti-pruss/am65x-sr2-pru0-pruhsr-fw.elf, size 37976
[   89.495225] remoteproc remoteproc12: unsupported resource 5
[   89.495253] remoteproc remoteproc12: remote processor 300b4000.pru is now up
[   89.495294] remoteproc remoteproc13: powering up 30084000.rtu
[   89.499778] remoteproc remoteproc13: Booting fw image ti-pruss/am65x-sr2-rtu0-pruhsr-fw.elf, size 34632
[   89.500937] remoteproc remoteproc13: remote processor 30084000.rtu is now up
[   89.500995] remoteproc remoteproc7: powering up 3008a000.txpru
[   89.502993] remoteproc remoteproc7: Booting fw image ti-pruss/am65x-sr2-txpru0-pruhsr-fw.elf, size 36128
[   89.503052] remoteproc remoteproc7: remote processor 3008a000.txpru is now up
[   89.503336] remoteproc remoteproc14: powering up 300b8000.pru
[   89.507154] remoteproc remoteproc14: Booting fw image ti-pruss/am65x-sr2-pru1-pruhsr-fw.elf, size 38208
[   89.507194] remoteproc remoteproc14: unsupported resource 5
[   89.507222] remoteproc remoteproc14: remote processor 300b8000.pru is now up
[   89.507263] remoteproc remoteproc15: powering up 30086000.rtu
[   89.508521] remoteproc remoteproc15: Booting fw image ti-pruss/am65x-sr2-rtu1-pruhsr-fw.elf, size 33844
[   89.508579] remoteproc remoteproc15: remote processor 30086000.rtu is now up
[   89.508621] remoteproc remoteproc8: powering up 3008c000.txpru
[   89.509885] remoteproc remoteproc8: Booting fw image ti-pruss/am65x-sr2-txpru1-pruhsr-fw.elf, size 34636
[   89.509939] remoteproc remoteproc8: remote processor 3008c000.txpru is now up
[   89.511371] pps pps1: new PPS source ptp2
[   93.603930] icssg-prueth icssg1-eth eth1: Link is Up - 1Gbps/Full - flow control off
[   93.604012] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   94.615095] hsr0: Slave B (eth2) is not up; please bring it up to get a fully working HSR network
root@am64xx-evm:~# [   94.616686] IPv6: ADDRCONF(NETDEV_CHANGE): hsr0: link becomes ready
[   94.628484] icssg-prueth icssg1-eth eth2: Link is Up - 1Gbps/Full - flow control off
[   94.628587] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready

root@am64xx-evm:~# [  119.203468] icssg-prueth icssg1-eth eth1: Link is Down
[  122.275639] icssg-prueth icssg1-eth eth1: Link is Up - 1Gbps/Full - flow control off

您可能对 DUT/中间板进行了任何其他配置吗？

-道林

尊敬的 Daolin：

首先、在所有电路板上、我们将禁用网络

systemctl disable dhcpcd.service
systemctl disable NetworkManager.service
systemctl disable systemd-resolved.service
systemctl disable systemd-networkd.service
sync
reboot

接下来是启用 HSR 的脚本

e2e.ti.com/.../hsr_5F00_setup.txt

命令是什么

sh ./ HSR_HW eth1 eth2 192.168.200.10 

此致

米兰

嗨、Milan：

只是为了澄清一下、我的结果是禁用了网络、正如我之前的一个回答中提到的那样！

我看到您在脚本中将转发模式设置为直通模式。 这与我使用默认存储转发的设置不同。 您是否对全部3个电路板使用了相同的脚本？ 也就是说、所有3个电路板上是否都使用了直通转发？ 我将尝试在我的设置中进行直通 iperf3测试。  

其他问题：

1. 您是否检查过此封包丢失发生在测试板1或测试板3作为中间板/DUT？ 这只是为了确保当前 DUT 板上不会出现此问题。

2. 我看到 iperf3服务器报告的传输大小和比特率是 iperf3客户端报告的~一半。 在仅两个器件之间测试 iperf3时、您是否看到相同的结果？ 也就是说、DUT 仅连接到另一个测试板、一个是 iperf3客户端、另一个是 iperf3服务器、然后查看是否还在 iperf3服务器上看到~一半的传输大小/比特率。

3.当你提到"我们没有电缆 C 在映像上,所以当发送数据包从测试板1到2,它只通过 DUT,应该转发数据包。" 这是否意味着您在设置中根本没有以太网电缆、或者您是在测试(以测试冗余)时断开电缆的连接？

4.您能否查看 DUT/middle board 的"ethtool -S eth1"和"ethtool -S eth2"统计数据,看看是否存在 TX 或 Rx 错误/掉线?

5.当 DUT 处于 HSR 非卸载模式时、能否检查是否看到相同的数据包丢失？

-道林

尊敬的 Daolin：

只有在我们使用时、我们才会看到该问题  切入直通。 此外、我们在 ethtool 统计数据中没有看到任何错误或丢失、我们注意到、如果数据包大小更大、就不会丢失数据包。 示例数据包大小1300 -丢失为13/19230 (0.068%)。  

您能否检查一下我们是否正在启用   切入直通  正确配置。 有关这方面的内容、我们将关注 TI 文档。

 我们 看到 iperf3服务器报告的传输大小和比特率~是 iperf3客户端报告的大小的一半。 但我们看不到在使用两个器件进行测试的情况。

第3点：我们为了这次测试从乞丐那里移除了电缆。 我们不确定它是出现 在测试板1还是测试板3上... 看起来与是 issyue  切入直通  

尊敬的 Daolin：

感谢您的快速响应！

您是对的、错误来自启用的队列数量！ 使用您提供的命令：

DevLink 开发参数设置 platform/icssg1-eth 名称 cut_thru 值 1. CPode 运行时间

我们没有看到任何数据包丢失!

我之前可能在08.XX 版本中跟踪了一个文档。。

Tianyi

您好、Tianyi、

感谢您分享您的发现、在我之前的回复中、EVM1作为 iperf3客户端、EVM3作为 iperf3服务器(与您目前看到数据包丢失的情况相同)、我发现在中间板/DUT/EVM2上仅配置一个 TX 队列以进行直通转发时、没有数据包丢失。  

但是、我在 EVM1 (作为 iperf3服务器)和 EVM3 (作为 iperf3客户端 )的  测试结果表明、在中间板/DUT/EVM2上仅配置一个 TX 队列以进行直通转发时、数据包丢失。 请参阅以下内容：

root@am64xx-evm:~# iperf3 -s -B 192.168.1.10
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.1.50, port 48842
[ 5] local 192.168.1.10 port 5201 connected to 192.168.1.50 port 53694
[ ID] Interval          Transfer    Bitrate        Jitter   Lost/Total Datagrams
[ 5]  0.00-1.00  sec 1.31 MBytes 11.0 Mbits/sec 0.022 ms 2819/6245 (45%) 
[ 5]  1.00-2.00  sec 1.34 MBytes 11.2 Mbits/sec 0.005 ms 2744/6251 (44%) 
[ 5]  2.00-3.00  sec 1.30 MBytes 10.9 Mbits/sec 0.010 ms 2831/6250 (45%) 
[ 5]  3.00-4.00  sec 1.30 MBytes 10.9 Mbits/sec 0.021 ms 2830/6238 (45%) 
[ 5]  4.00-5.00  sec 1.31 MBytes 11.0 Mbits/sec 0.011 ms 2832/6260 (45%) 
[ 5]  5.00-6.00  sec 1.30 MBytes 10.9 Mbits/sec 0.011 ms 2840/6251 (45%) 
[ 5]  6.00-7.00  sec 1.30 MBytes 10.9 Mbits/sec 0.008 ms 2849/6251 (46%) 
^C[ 5]  7.00-7.49  sec  638 KBytes 10.7 Mbits/sec 0.008 ms 1429/3061 (47%) 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval          Transfer    Bitrate        Jitter   Lost/Total Datagrams
[ 5]  0.00-7.49  sec 9.78 MBytes 11.0 Mbits/sec 0.008 ms 21174/46807 (45%) receiver
iperf3: interrupt - the server has terminated 

我注意到、切换中间板/DUT/EVM2上的电缆连接不会导致相同配置的数据包丢失(例如、从 EVM2 eth1 <--> EVM3 和 EVM2 eth2 <--> EVM1切换电缆、使 EVM2 eth1 <--> EVM1和 EVM2 eth2 <--> EVM3)。

这似乎意味着在 EVM1上从 eth2转发到 eth1不会丢失数据包、但出于某种原因 eth1转发到 eth2会导致数据包丢失。

在导致数据包丢失的设置中、数据包是否从 eth1转发到 eth2？

root@am64xx-evm:~# iperf3 -s -B 192.168.1.10
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.1.50, port 42484
[ 5] local 192.168.1.10 port 5201 connected to 192.168.1.50 port 45543
[ ID] Interval          Transfer    Bitrate        Jitter   Lost/Total Datagrams
[ 5]  0.00-1.00  sec 2.38 MBytes 20.0 Mbits/sec 0.008 ms 0/6245 (0%) 
[ 5]  1.00-2.00  sec 2.38 MBytes 20.0 Mbits/sec 0.006 ms 0/6251 (0%) 
[ 5]  2.00-3.00  sec 2.38 MBytes 20.0 Mbits/sec 0.008 ms 0/6249 (0%) 
[ 5]  3.00-4.00  sec 2.38 MBytes 20.0 Mbits/sec 0.007 ms 0/6252 (0%) 
[ 5]  4.00-5.00  sec 2.38 MBytes 20.0 Mbits/sec 0.005 ms 0/6249 (0%) 
[ 5]  5.00-6.00  sec 2.38 MBytes 20.0 Mbits/sec 0.005 ms 0/6251 (0%) 
[ 5]  6.00-7.00  sec 2.38 MBytes 20.0 Mbits/sec 0.007 ms 0/6248 (0%) 
[ 5]  7.00-8.00  sec 2.38 MBytes 20.0 Mbits/sec 0.004 ms 0/6252 (0%) 
[ 5]  8.00-9.00  sec 2.38 MBytes 20.0 Mbits/sec 0.006 ms 0/6249 (0%) 
[ 5]  9.00-10.00 sec 2.38 MBytes 20.0 Mbits/sec 0.004 ms 0/6251 (0%) 
[ 5] 10.00-11.00 sec 2.38 MBytes 20.0 Mbits/sec 0.005 ms 0/6249 (0%) 
^C[ 5] 11.00-11.51 sec 1.22 MBytes 20.0 Mbits/sec 0.006 ms 0/3206 (0%) 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval          Transfer    Bitrate        Jitter   Lost/Total Datagrams
[ 5]  0.00-11.51 sec 27.4 MBytes 20.0 Mbits/sec 0.006 ms 0/71952 (0%) receiver
iperf3: interrupt - the server has terminated 

您是否可以尝试切换 DUT 上的电缆连接？  数据包丢失仅朝一个方向出现是很奇怪的、因此我只想检查它是否不是特定的接口问题。

-道林

尊敬的 Daolin：

是的、我已经尝试在 EVM2中切换电缆连接。 一个方向会导致某些数据包丢失。

根据测试、当 EVM2 (转发)具有以下配置时：

- ETH2 :从 EVM1 / Rx 接收

- eth1 :转发到 EVM3 /Tx

没有数据包丢失。

当 EVM2具有以下配置时：

- eth1 :从 EVM1 / Rx 接收

- eth2 :转发到 EVM3/Tx

我们有大量的数据包。

我观察到的另一件事(也许这可以帮助你)是,使用 ethtool :

ethtool -S ethx

即使在转发操作期间有一些数据包丢失(也通过使用 EVM1 <->EVM2和 EVM2 <->EVM3之间的2个 Profisharks 确认), EVM2上显示的值:

ethtool -S ethx | rx_good_frames

或者

ethtool -S ethx | TX_GOOD_FRAMES

没有显示任何数据包丢失...

Tianyi

您好、Tianyi、

MAC 硬件统计信息 ethtool -S ethX 未显示丢失帧的事实似乎意味着在 EVM2的网络堆栈中、大约一半的数据包只是没有被转发并到达出口以太网端口。  

此外、从 eth2到 eth1的直通问题不会导致数据包丢失、但从 eth1到 eth2的直通问题会导致数据包丢失、我会向内部团队核实可能的原因。

我将在明天之前回复最新消息。

-道林

尊敬的 Daolin：

感谢您的快速更新。 如果您需要我们的任何支持、请随时与我们联系！

此功能直通对我们的客户非常重要！ 他们需要这个在六月中旬...

Tianyi

最新动态：

我已经就此提交了一份内部错误报告、因为这似乎是一个错误。

开发团队的快速意见是打印数据包聚合器(PA)统计信息0x300a7000 - 0x300a7300、您能否打印出这些寄存器地址的内容？

在 Linux 用户空间中、您可以使用 devmem2来执行此操作、这里是我使用的 bash 脚本、但可以随意使用您想要打印 PA 内容的任何工具。

#!/bin/sh

startaddr=$1
endaddr=$2
inc=$3
range=$(($endaddr-$startaddr))

echo "startaddr=$startaddr"
echo "endaddr=$endaddr"
echo "range="
printf '%x\n' "$range"

addr=$startaddr
for ((i=1;i<=$range;i++));
do
	hex_number=$(printf "%x" "$addr")
	echo "readaddr=$hex_number"
	devmem2 $addr | grep Read | cut -d " " -f 7 | tee -a PA_stats.txt
	echo " "
	addr=$(($addr+$inc)) 
done

-道林

您好、Tianyi、

感谢您分享这些价值观。 我注意到 EVM1和 EVM2的 PA_Stats 打印输出比预期的768个值长很多。  我想您可能已经将这些寄存器的内容转储了两次、并附加到了同一个文件中。 您是否能够再次将内容转储到每个 EVM 的文件中？ 具体查找768个值。

不幸的是,我目前没有时间线,什么时候可以解决错误。 我了解该问题的紧迫性、并且我们仍在努力了解 PA 统计数据的结果。 我将在下周回复最新消息。

-道林

您好、Tianyi、

就像更新一样、开发团队仍在分析 此问题的根本原因(具有高优先级)。

我们发现、该问题是在标准直通转发(即使没有 HSR 设置)中发现的、这可能是在采用直通转发的 HSR 设置中发现的导致该问题的原因。

我仍在尝试从团队获得一个估计的时间范围以进行修复。

感谢您的耐心。

-道林

尊敬的 Daolin：

我回到你来检查是否有任何关于这个问题的更新! 还有、您是否知道错误是来自 PRU 固件还是 Linux 内核代码？

Tianyi

您好、Tianyi、  

对延迟回复深表歉意！ 本周我没有参加培训、所以我想要了解最新的调试状态。 根据我本周早些时候的理解：

1. 固件不丢弃任何数据包(当我们通知 TX_PRU 添加 CRC 错误或不添加直通帧时、在 RTU eof 期间检查)

2.捕获了 Wireshark、看起来接收 EVM (EVM3)无法接收某些数据包  

3. 至少从我们在固件中的计数器中,转发路径上没有中断

我无法确认这是意味着错误位于 PRU 固件还是 Linux 内核中。 我将与软件团队了解当前调试情况、下周同一时间再见。

-道林

Tianyi/Milan,

本周 PRU 固件专家更新：

我 在转发 DUT 的两侧连接了 Profishark、所有数据包都在转发、但其中一些数据包在转发过程中损坏、因此导致了问题。
我在固件上进行了一些更改、能够使 TCP 正常工作、但每秒进行大量重试

似乎有一个有希望的固件更改可以解决该问题(没有32B 块损坏、没有前导码损坏)、但固件专家仍然说、此更改有两个问题(Profishark 捕获的额外1字节前导码0x55、Tx 下溢问题)。

这个问题仍然是我们的首要问题、但固件团队一直难以进行调试(此时似乎是 PRU 固件中的问题)、因此我没有确定修复时间的时间表。

-道林

尊敬的 Daolin：

我测试了转发可能在直通模式 (HSR)下引入的延迟、并观察到延迟随着数据包大小的增加而增加。 这种行为似乎相符 存储和转发模式 而不是直通模式...  

我们使用3个板 EVM 进行了测试

EVM1 <->Profishark1 (Profitap1)<->EVM2 <->Profishark2 (Profitap2)<->EVM3

我们将数据包从 EVM1发送到 EVM3、并将数据包标记为 Profishark 1和2

对于400B 数据包：

平均值= 5.231us
最大值= 5.350us

对于1300B 数据包：

平均值= 12.398us
最大值= 12.526us

在这里你可以找到脚本:

#!/bin/sh

#ffload - sh hsr_setup.sh hsr_sw <INTF_A> <INTF_B> <HSR_INTF_IP_ADDR> 
#For non offload - sh hsr_setup.sh hsr_hw <INTF_A> <INTF_B> <HSR_INTF_IP_ADDR> 

echo "$@"

if [ "$#" -ne "4" ]
then
    echo "usage:"
    echo "$0 <hsr_sw/hsr_hw/cut-thru> <intf1> <intf2> <IPaddress>"
    exit
fi

if [ "$1" != "hsr_hw" ] && [ "$1" != "hsr_sw" ] && [ "$1" != "cut-thru" ]
then
    echo "the first argument must be 'hsr_hw', 'hsr_sw' or 'cut-thru'."
    exit
fi

if=hsr0 

ifa=$2 
ifb=$3 

ip=$4 
mac=`ifconfig $ifa | grep ether | cut -d " " -f 10` 
# Hardcode the device name
device="platform/icssg1-eth"
#device+=`dmesg | grep $ifa | grep icssg-prueth | grep -m 1 "Link is Up" | awk '{print $4}'` 

echo "ip=$ip" 
echo "if=$if" 
echo "mac=$mac" 
echo "slave-a=$ifa" 
echo "slave-b=$ifb" 
echo "device=$device" 

ip link delete hsr0  2> /dev/null 

ip link set $ifa down 
ip link set $ifb down 
sleep 1 

if [ "$1" == "hsr_hw" ] 
then 
        ethtool -k "$ifa" | grep hsr
        ethtool -K "$ifa" hsr-fwd-offload on
        ethtool -K "$ifa" hsr-dup-offload on
        ethtool -K "$ifa" hsr-tag-ins-offload on
        ethtool -K "$ifa" hsr-tag-rm-offload on
        ethtool -k "$ifa" | grep hsr

        ethtool -k "$ifb" | grep hsr
        ethtool -K "$ifb" hsr-fwd-offload on
        ethtool -K "$ifb" hsr-dup-offload on
        ethtool -K "$ifb" hsr-tag-ins-offload on
        ethtool -K "$ifb" hsr-tag-rm-offload on
        ethtool -k "$ifb" | grep hsr

        devlink dev param set "$device" name hsr_offload_mode value true cmode runtime

        sleep 3 

        # Enable Cut-Through : 
        devlink dev param set "$device" name cut_thru value 1 cmode runtime
fi

ip link set dev $ifa address $mac 
ip link set dev $ifb address $mac 

ip link set $ifa up 
sleep 1 

ip link set $ifb up 
sleep 1 

ip link add name $if type hsr slave1 $ifa slave2 $ifb supervision 45 version 1 

sleep 3 

ip addr add $ip/24 dev $if 
ip link set $if up 

Tianyi

您好、Tianyi、

只是为了澄清一下、使用这种测试延迟的设置、您是否在没有丢失数据包的情况下在转发方向上进行测试、我们之前讨论的是(eth2-->eth1)？ 根据我的记忆、eth1-->eth2是有问题的转发路径。

实际上是昨天我测试了以下几种组合

1. 100Mbps 与1Gbps

2.使用直通与无 HSR 直接直通进行 HSR 卸载

3. iperf3 UDP 20M vs 90m vs 200m

4. eth1->eth2方向 vs eth2-->eth1方向

我看到了这与 Iperf 3 IdP 20米 (iperf3 -c 192.168.200.2 -t 10 -b 20米 -l 400 -u -您使用的相同命令)、1Gbps、HSR 卸载(直通)、两个转发方向、我不再看到我们最初看到的丢失的数据包。 不过、AT 较高的比特率 (iperf3 -c 192.168.200.2 -t 10 -b 200m -l 400 -u)、我看到两个方向的数据报丢失。 我今天需要对其进行仔细检查、以防我的设置出现问题、因为它看起来与我们以前看到的问题不同。 自几周前的上次测试后、我没有更改 PRU 固件和 Linux 内核。

作为对您的报告的完整性检查、您在这里看到的有关更大数据包的直通显示更大延迟的报告、您能否检查只是直通交换机设置是否出现了相同的情况  之间的比较 HSR？ 下面是我用于设置直通的脚本  否  HSR。

#!/bin/sh

#Setup Cut through switching (without HSR)

if [ "$#" != "4" ]
then
        echo "$0 <portA> <portB> <ethernet type> <ip addr/16>"
        exit
fi

portA=$1
portB=$2
enettype=$3
ipaddr=$4

ip link set br0 down
sleep 1
ip link delete br0 2> /dev/null
sleep 1

if [ "$3" == "icssg" ]
then
	ip link set dev $portA down
	ip link set dev $portB down
	devlink dev param set platform/icssg1-eth name switch_mode value 1 cmode runtime
	ip link add name br0 type bridge
	ip link set dev $portA master br0
	ip link set dev $portB master br0
	ip link set dev br0 up
	devlink dev param set platform/icssg1-eth name cut_thru value 1 cmode runtime
	ip link set dev $portA up
	sleep 1
	ip link set dev $portB up
	sleep 1
	ip addr add $ipaddr dev br0
	bridge vlan add dev br0 vid 1 pvid untagged self
elif [ "$3" == "cpsw" ]
then
	ip link set dev $portA down 
	ip link set dev $portB down
	devlink dev param set platform/8000000.ethernet name switch_mode value true cmode runtime
	echo 1 > /sys/kernel/debug/8000000.ethernet/Port1/cut_thru_rx_pri_mask
	echo 1 > /sys/kernel/debug/8000000.ethernet/Port1/cut_thru_tx_pri_mask
	echo 1 > /sys/kernel/debug/8000000.ethernet/Port2/cut_thru_rx_pri_mask
	echo 1 > /sys/kernel/debug/8000000.ethernet/Port2/cut_thru_tx_pri_mask
	ethtool --set-priv-flags $portA cut-thru on
	ethtool --set-priv-flags $portB cut-thru on
	ip link add name br0 type bridge
	ip link set dev br0 type bridge ageing_time 1000
	ip link set dev $portA up
	sleep 1
	ip link set dev $portB up
	sleep 1
	ip link set dev $portA master br0
	ip link set dev $portB master br0
	ip link set dev br0 type bridge stp_state 1
	ip link set dev br0 up
	ip addr add $ipaddr dev br0
	bridge vlan add dev br0 vid 1 self
	bridge vlan add dev br0 vid 1 pvid untagged self
fi
	

-道林

您能否提供您为不带 HSR 的测试直通交换机执行的命令？

Tianyi

您好、Tianyi、  

>>重新执行测试时、是否拔下了 EVM1和 EVM3之间的电缆？  

好的、我忘记移除直接的电缆连接了。 我将再次对其进行测试以确保正常运行。  

您是否可以提供您对没有 HSR 的测试直通交换机执行的命令？

这是我用于 HSR 直接直通的脚本。 只需确保选择"icssg"、而不是"cpsw"。

#!/bin/sh

#Setup Cut through switching (without HSR)

if [ "$#" != "4" ]
then
        echo "$0 <portA> <portB> <ethernet type> <ip addr/16>"
        exit
fi

portA=$1
portB=$2
enettype=$3
ipaddr=$4

ip link set br0 down
sleep 1
ip link delete br0 2> /dev/null
sleep 1

if [ "$3" == "icssg" ]
then
	ip link set dev $portA down
	ip link set dev $portB down
	devlink dev param set platform/icssg1-eth name switch_mode value 1 cmode runtime
	ip link add name br0 type bridge
	ip link set dev $portA master br0
	ip link set dev $portB master br0
	ip link set dev br0 up
	devlink dev param set platform/icssg1-eth name cut_thru value 1 cmode runtime
	ip link set dev $portA up
	sleep 1
	ip link set dev $portB up
	sleep 1
	ip addr add $ipaddr dev br0
	bridge vlan add dev br0 vid 1 pvid untagged self
elif [ "$3" == "cpsw" ]
then
	ip link set dev $portA down 
	ip link set dev $portB down
	devlink dev param set platform/8000000.ethernet name switch_mode value true cmode runtime
	echo 1 > /sys/kernel/debug/8000000.ethernet/Port1/cut_thru_rx_pri_mask
	echo 1 > /sys/kernel/debug/8000000.ethernet/Port1/cut_thru_tx_pri_mask
	echo 1 > /sys/kernel/debug/8000000.ethernet/Port2/cut_thru_rx_pri_mask
	echo 1 > /sys/kernel/debug/8000000.ethernet/Port2/cut_thru_tx_pri_mask
	ethtool --set-priv-flags $portA cut-thru on
	ethtool --set-priv-flags $portB cut-thru on
	ip link add name br0 type bridge
	ip link set dev br0 type bridge ageing_time 1000
	ip link set dev $portA up
	sleep 1
	ip link set dev $portB up
	sleep 1
	ip link set dev $portA master br0
	ip link set dev $portB master br0
	ip link set dev br0 type bridge stp_state 1
	ip link set dev br0 up
	ip addr add $ipaddr dev br0
	bridge vlan add dev br0 vid 1 self
	bridge vlan add dev br0 vid 1 pvid untagged self
fi

-道林

最新动态：

我再次进行了测试、以确保 EVM1和 EVM3之间的直接电缆连接断开、我看到了以下结果。 目前、通过这些测试、我的设置中的 PRU 固件或 Linux 内核没有变化。

测试1： 检查是否仍出现直通的单向下降框架  
设置： 在全部3个 EVM 上通过直通模式减轻 HSR 负载、 线路速率为1Gbps 、iperf3 UDP、20M 比特率
结果：  数据包丢失仅在 eth1-->eth2路径上、尽管我不再观察到~50%的损失、传输大小不再是10-11兆位/秒、现在看到20Mbit/s、但数据报丢失、PRU 固件或 Linux 内核与以前没有变化

EVM3 (Receiver) Iperf3 results
[  5] local 192.168.1.50 port 5201 connected to 192.168.1.10 port 60797
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  2.37 MBytes  19.9 Mbits/sec  0.011 ms  8/1785 (0.45%)  
[  5]   1.00-2.00   sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  0/1785 (0%)  
[  5]   2.00-3.00   sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  0/1786 (0%)  
[  5]   3.00-4.00   sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  0/1786 (0%)  
[  5]   4.00-5.00   sec  2.38 MBytes  19.9 Mbits/sec  0.009 ms  4/1785 (0.22%)  
[  5]   5.00-6.00   sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  2/1786 (0.11%)  
[  5]   6.00-7.00   sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  2/1786 (0.11%)  
[  5]   7.00-8.00   sec  2.38 MBytes  20.0 Mbits/sec  0.010 ms  0/1786 (0%)  
[  5]   8.00-9.00   sec  2.38 MBytes  20.0 Mbits/sec  0.010 ms  3/1785 (0.17%)  
[  5]   9.00-10.00  sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  0/1786 (0%)  
[  5]  10.00-11.00  sec  2.38 MBytes  20.0 Mbits/sec  0.011 ms  1/1786 (0.056%)  
[  5]  11.00-12.00  sec  2.35 MBytes  19.7 Mbits/sec  0.010 ms  27/1785 (1.5%)  
[  5]  12.00-13.00  sec  2.30 MBytes  19.3 Mbits/sec  0.008 ms  62/1786 (3.5%)  
[  5]  13.00-14.00  sec  2.34 MBytes  19.6 Mbits/sec  0.009 ms  35/1786 (2%)  
[  5]  14.00-15.00  sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  4/1786 (0.22%)  
[  5]  15.00-16.00  sec  2.36 MBytes  19.8 Mbits/sec  0.010 ms  21/1785 (1.2%)  
[  5]  16.00-17.00  sec  2.36 MBytes  19.8 Mbits/sec  0.012 ms  19/1786 (1.1%)  
[  5]  17.00-18.00  sec  2.37 MBytes  19.8 Mbits/sec  0.009 ms  14/1786 (0.78%)  
[  5]  18.00-19.00  sec  2.38 MBytes  19.9 Mbits/sec  0.010 ms  5/1785 (0.28%)  
[  5]  19.00-20.00  sec  2.35 MBytes  19.7 Mbits/sec  0.010 ms  24/1786 (1.3%)  
[  5]  20.00-21.00  sec  2.36 MBytes  19.8 Mbits/sec  0.027 ms  22/1786 (1.2%)  
[  5]  21.00-22.00  sec  2.37 MBytes  19.9 Mbits/sec  0.035 ms  11/1786 (0.62%)  
[  5]  22.00-23.00  sec  2.37 MBytes  19.9 Mbits/sec  0.016 ms  9/1785 (0.5%)  
[  5]  23.00-24.00  sec  2.38 MBytes  20.0 Mbits/sec  0.011 ms  0/1786 (0%)  
[  5]  24.00-25.00  sec  2.38 MBytes  20.0 Mbits/sec  0.011 ms  0/1786 (0%)  
[  5]  25.00-26.00  sec  2.38 MBytes  20.0 Mbits/sec  0.008 ms  0/1785 (0%)  
[  5]  26.00-27.00  sec  2.38 MBytes  20.0 Mbits/sec  0.008 ms  3/1786 (0.17%)  
[  5]  27.00-28.00  sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  0/1786 (0%)  
[  5]  28.00-29.00  sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  2/1786 (0.11%)  
[  5]  29.00-30.00  sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  0/1785 (0%)  
[  5]  30.00-31.00  sec  2.38 MBytes  20.0 Mbits/sec  0.008 ms  0/1786 (0%)  
[  5]  31.00-32.00  sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  3/1786 (0.17%)  
[  5]  32.00-33.00  sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  0/1785 (0%)  
[  5]  33.00-34.00  sec  2.38 MBytes  20.0 Mbits/sec  0.010 ms  2/1786 (0.11%)  
[  5]  34.00-35.00  sec  2.38 MBytes  20.0 Mbits/sec  0.010 ms  0/1786 (0%)  
[  5]  35.00-36.00  sec  2.38 MBytes  19.9 Mbits/sec  0.013 ms  7/1786 (0.39%)  
[  5]  36.00-37.00  sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  1/1785 (0.056%)  
[  5]  37.00-38.00  sec  2.38 MBytes  20.0 Mbits/sec  0.008 ms  4/1786 (0.22%)  
[  5]  38.00-39.00  sec  2.38 MBytes  20.0 Mbits/sec  0.009 ms  2/1786 (0.11%)  
[  5]  39.00-40.00  sec  2.37 MBytes  19.9 Mbits/sec  0.010 ms  8/1785 (0.45%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-40.00  sec  95.0 MBytes  19.9 Mbits/sec  0.010 ms  305/71427 (0.43%)  receiver

测试2： 与测试1相同、但不同 200m 比特率
设置： 通过直通所有 EVM 来减轻 HSR 负载、 线路速率为1Gbps 、200m 比特率下 iperf3 UDP
结果： 数据包在两个方向上丢失！  

测试3： 与测试1相同、但速率为100Mbps 时除外
设置： 通过直通所有 EVM 来减轻 HSR 负载、 100Mbps 线路速率、 在20M 比特率下的 iperf3 UDP
结果： 双向0数据包丢失

测试4： 与测试3相同、但95M 比特率除外
设置： 通过直通所有 EVM 来减轻 HSR 负载、 100Mbps 线速率 、iperf3 UDP at 95M 比特率
结果： 仅在 eth1-->eth2方向丢失数据包  

因此、由于某种原因、尽管几周前可以看到、但我无法再重现与您所看到的完全相同的结果、尽管我仍然看到 eth1->eth2路径丢失数据包的问题。

在 HSR 卸载直通模式下、PRU 固件团队即将获得不会丢失数据包的固件版本。 收到该固件后、我将再次运行这些测试、以查看我观察到的问题是否已修复。

-道林

尊敬的 Daolin：

感谢您发送编修。

新固件 100Mbps 线速率 根据您的测试3和我们的测试、我们可以说没有数据包丢失 ！ 但是、我们观察到、在100Mbps 线路速率下启用直通时、除了存储和转发行为外、我们没有直通行为。

我们使用3个板 EVM 进行了测试

EVM1 <->Profishark1 (Profitap1)<->EVM2 <->Profishark2 (Profitap2)<->EVM3

我们将数据包从 EVM1发送到 EVM3、并将数据包标记为 Profishark 1和2

以下是我们观察到的结果：

为400B

平均值= 39.256us

最大值= 39.433us

用于1300B

平均值= 111.211us

最大值= 111.424us

这种行为似乎不会被切断...是否有可能在你的一方重现这一点? 这是比1Gbips 速度与丢包问题更紧急...

Tianyi

您好、Tianyi、

我应该强调" 测试4 "我在上一次回复中分享的结果。 在以100Mbps 线路速率传输95Mbps UDP 吞吐量的情况下、eth1->eth2转发路径中仍然有数据包丢失。

我刚刚收到一个内部 PRU 固件版本、该版本可以修复该线程中的原始问题(在单个转发路径上丢弃数据包以通过直通方式卸载 HSR)、因此我将首先测试该版本的固件、包括100Mbps 线路速率。

在我们确保直通特性正常工作后、如果我们看到数据包大小增加时出现同样的行为、从而导致延迟增加、我可以尝试与我们的开发团队(他们位于印度)合作进行测试。 我不能直接在我身边复制这个,作为我的设置(在美国),因为我们没有可用的 profitaps/profisharks。

我将在今天晚些时候回复一个更新。

-道林

最新动态：

使用内部共享的新 PRU 固件、我运行了多项测试、现在看到了以下结果

通过新固件的直通测试减轻 HSR 的负载：

测试1：1Gbps 线路速率、20Mbps UDP iperf、双向无连续丢失数据包

测试2：1Gbps 线路速率、200Mbps UDP iperf、双向都有连续丢失数据包

测试3：100Mbps 线路速率、20Mbps UDP iperf、双向无连续丢失数据包

测试4：100Mbps 线路速率、95Mbps UDP iperf、双向无连续丢失数据包

如您所见、在更高的吞吐率下、我们会看到数据包丢失、但会在两个方向上而不是在一个方向上。

但是、我知道您的团队主要关心的是通过直通以100Mbps 速率减轻 HSR 负载、因此此版本的固件足以满足您的用例需求。 我能否确认这是否适合您的团队、或者您预计是否需要更高的吞吐率？

-道林

P.S.我的回复将推迟到7月10日,因为我将在美国7月4日休假

尊敬的 Daolin：

感谢您的快速响应和更新。 这对我们来说是一个好消息!

是的、您是对的、我们当前的目标是 100Mbps 线路速率直通模式。

如果我理解得当、我们有2个主要问题：

-以100Mbps 丢失数据包

-以100Mbps 转发时间(400B ~39.256us 和1300B ~111.211us)

从前面的评论,数据包丢失100Mbps 似乎是固定的!

我们仍然可能有这种转发时间(直通模式) 100Mbps 的行为存储和转发。

你可以找到上面的详细测试!

"<->"=以太网电缆

EVM1 <->Profishark1 <->EVM2 <->Profishark2 <->EVM3

Profisharks 同步并具有相同的时基。

我们断开 EVM1和 EVM3之间的电缆、使数据包仅通过 EVM2 (DUT )。

1我们在 Profisharks 上开始拍摄

2在 EVM3上启动 iperf 服务器

3我们在 EVM1上启动 iperf 客户端 UDP：

比如 Test 3 100Mbps 线路速率、10s 期间20Mbps UDP iperf

4我们停止捕获 Profisharks (两者)

5我们有一个脚本,可以检索目标数据包,并对 Profishark2和 Profishark1生成的 pcap 文件之间的时间戳进行区分

6我们得到时间戳差异的最大值和平均值!

如果你需要一个会议来帮助设置测试台感到自由地问!

再次感谢您的更新!

Tianyi

您好、Tianyi、

感谢您确认您的要求和直通延迟设置的详细信息。

根据发送给您和您的团队的电子邮件、我们的固件专家会要求您的团队提供以下测试结果。 请尝试一下、如果您看到的问题与以前是否相同、请告诉我们。  

• 100Mbps 时的停留时间(400B ~39.256us 和1300B ~111.211us)：
  • 对于两个方向 eth1->eth2和 eth2->eth1、启用直通模式的接口是分开的。
  • 请尝试使用以下命令来启用直通模式：(设置位0和位8)
    DevLink 开发参数设置 platform/icssg1-eth name cut_tru value 257 cmode 运行时

我们的固件专家在同一封电子邮件中提供了解决100Mbps 数据包丢失问题的固件版本。

只是为了澄清一下  100Mbps 时的转发时间(400B ~39.256us 和1300B ~111.211us)  是否在常规直通转发(无 HSR 设置)的情况下观察到了？

-道林

您好、Tianyi、

正如今天的会议所讨论的那样、我询问开发团队、具有 queue1和 queue8的直通配置是否是直通功能所需的配置。 以下是反馈：

• 要在两个方向上启用直通转发、需要在切片0和切片1上均启用直通
• 用于启用直通的 devlink 命令采用 U16值。 它的全部16位表示队列。 8表示切片0、8表示切片1。
• 位0至位7是 slice0队列、位8至位15是 slice1队列。 这就是为什么需要将 bit0和 bit8配置为使用 devlink 命令直通才能配置 queue1的原因。  我认为混淆可能是设置 bit0和 bit8并不意味着设置 queue1和 queue8。 仅表示为层0设置了 queue1、为层2设置了 queue1、以启用双向直通。
• 例如、如果您需要为切片0和切片1在 Q0和 Q1上启用直通、则需要传递设置位0、1、8、9的 U16值、即必须以十进制传递"0000 0011 0000 0011"= 771。

  未来我们将在 software-dl.ti.com/.../Foundational_Components PRU-ICSS / Linux_Drivers / PRU_ICSSG_ICSSG.html 中对其进行更新 Ethernet_Switch。

最近共享的固件和原始固件中发生了什么变化？

"我们最近转向了 ICSSG 的333MHz、这给剪切模式带来了问题-在固件中修复了它。 (这将导致1G 切换的停留时间增加、100M/10M 与之前相同)。"

-道林

尊敬的 Daolin：

感谢您的更新。 现在更清楚了!

Tianyi Liu

您好、Tianyi、

我只是想问一下、您的团队是否有特定的直通转发延迟要求？  

从您之前在 E2E 上的回复中、您表示在400B 时您观察到~40us 延迟、但在两周的通话中您口头提到会看到6us 延迟。 我假设这6us 延迟是通过电子邮件与您共享的较新固件更换的延迟？ 我的理解是否正确？

此外、您在通话中提到、与您共享的新固件似乎也解决了随着数据包大小的增加而增加直通转发延迟的问题。 我只想在这里确认、这个仍然正确？

-道林

您好、Tianyi！

您能回答我之前的问题吗？ 我们希望确保我们与您的项目所追求的贯穿绩效保持一致。

-道林

尊敬的 Daolin：

是的。 当我在100Mbps 直通测试时,我们有~6us 的延迟来转发400B 和1300B 的数据包!

-天一

我记得100 Mbps 的链路速度、确实如此 不是数据包 丢失。

但对于1Gbps、则存在 一些数据包会变得很难闻 向一个方向转发数据包时

示例：

          (EVM1 <->EVM2 <->EVM3)。

          EVM2 eth1输入 eth2输出或 EVM2 eth1输出 eth2输入

您好、Tianyi、

感谢您的确认！

如电子邮件所述、我们将了解在 未来版本中对 PRU 固件在1Gbps 用例中的改进。 您在电子邮件中提到、您计划在年底之前解决此问题、这是正确的吗？

您的团队是否有特定的直通转发延迟要求？  [报价]

此外、您对上述问题有具体要求吗？

-道林

道林：

 同样、我正在使用 AM6442上的 PRU_ICSSG (实际上在目标应用中使用了全部3个 RJ45端口)、因此我现在要密切关注这一点。  

我们是否正在查看 AM64x 工业通信 SDK v10 以了解"1Gbps 用例中 PRU 固件的改进"？  

我希望两者都是这样

(+) Thomas Leyrer 的个人资料- Thomas Leyrer - TI E2E 支持论坛 和 (+) Pekka VARiS 的个人资料- Pekka VARiS - TI E2E 支持论坛 将对其进行测试。

谢谢

吉姆

Jim、您好！

感谢您的咨询

我们将在 未来版本中着眼于对1Gbps 用例下 PRU 固件的改进

为了澄清这一点、具体而言、我将讨论 HSR PRU 固件可降低数据包丢失的问题、当 ICSSG 以太网端口配置为卸载 HSR 并在一个方向(另一个方向不存在数据包丢失)使用直通转发时会出现这种问题。 在 RT-Linux 上发现了该问题： https://www.ti.com/tool/download/RT-Linux PROCESSOR-SDK-LINUX-RT AM64X-AM64X。  

我们是否正在关注 AM64x 工业通信 SDK v10 中的"1Gbps 用例下 PRU 固件的改进"？  [报价]

  这是工业通信 SDK 吗？    RTOS - INDUSTRIAL-COMMUNICATIONS-SDK—适用于 AM64x-RTOS 的工业通信 SDK

如果是、请注意在此线程中观察到的问题是在 Linux/RT-Linux 上观察到的。 我不知道 Thomas 或 Pekka 是否在工业通信 SDK 上测试了该功能、是否出现了类似问题。

-道林

Daolin -我的应用确实需要 RT-Linux；我将 A53用于这些高速通信路径。

有意思的是、" tirex"路径在  描述中列出了适用于 AM64x 的工业通信 SDK、但并未说明其本身仅适用于 RTOS (出现了一个不同的问题、然后是 Linux 对所述工业通信 SDK 的支持(我会为此输入不同的 e2e)。

Jim、您好！

感谢您的澄清。 以下是我根据您共享的 tirex 链接并进入"用户指南"部分找到的内容。 但是、请为此查询创建一个单独的 e2e、以使该线程专注于具有直通转发的 HSR 卸载。

"欢迎观看 适用于 AM64X 的工业通信 SDK。 此 SDK 包含用于  在 PRU-ICSS 上开发基于 RTOS 和非 RTOS 的工业通信、现场总线和网络应用的示例、库和工具

-道林