关于openharmony:OpenHarmony-LiteosA内核之iperf3移植心得

3次阅读

共计 5256 个字符，预计需要花费 14 分钟才能阅读完成。

iperf3 次要的性能是测试基于特定门路的带宽，在客户端和服务器端建设连贯（三次握手）后，客户端发送肯定大小的数据报并记下发送的工夫，或者客户端在肯定的工夫内发送数据并记下发送的总数据。带宽的大小等于发送的总数据除以发送的总工夫。对服务器端来说，在连贯建设工夫内，接管的总数据除以所花工夫即为服务器端所测得的带宽。

iperf3 测试 UDP 的性能时，客户端能够指定 UDP 数据流的速率。客户端发送数据时，将依据客户提供的速率计算数据报发送之间的时延，客户还能够指定发送数据报的大小。每个发送的数据报蕴含一个 ID 号，用来惟一地标识该报文。服务器端则依据该 ID 号来确定数据报失落和乱序。当把 UDP 报文大小设置能够将整个报文放入 IP 层的包（packet）内时，那么 UDP 所测得的报文失落数据即为 IP 层包的失落数据。这提供了一个无效的测试包失落状况的办法。数据报传输提早抖动（Jitter）的测试由服务器端实现，客户发送的报文数据蕴含有发送工夫戳，服务器端依据该工夫信息和接管到报文的工夫戳来计算传输提早抖动。传输提早抖动反映传输过程中是否平滑。因为它是一个相对值，所以并不需要客户端和服务器端工夫同步。

由上介绍咱们能够晓得 iperf3 的性能减少了操作系统网络度量的能力，而携带 Liteos_A 内核的 OpenAtom OpenHarmony（以下简称“OpenHarmony”）操作系统目前还不反对这个性能，特此尝试把 iperf3 移植到反对 Liteos_A 内核的 OpenHarmony 操作系统中，并作此文分享一些心得。

iperf3 能够运行在 Linux 和 Windows 平台下，其应用了规范的 POSIX 接口，因而将 iperf3 移植到 Liteos_A 上，目前 Liteos_A 反对用户态和内核态的命令，这个也造成了移植的很大艰难，所以以下将 2 种增加命令的形式都记录下，供读者参考。

确定库的类型
OpenHarmony 有如下几种指标类型：

executable: 生成可执行文件，对于 Liteos_A, 在目录 /bin 下能够找到可执行文件

shared_library: 生成.dll 或.so 动态链接库、对于 Liteos_A, 在目录 /lib 或者 /usr/lib 下能够找到动静库

static_library: 生成.lib 或.a 动态链接库

group: 生成依赖关系组

action: 运行脚本以生成文件

依据以上几种类型的形容可知，将 iperf3 移植成 executable 类型的组件最为适合。

增加库到工程中

将源码下载到 Linux 下并解压，执行./configure，生成 iperf_config.h，将 iperf3 的源码拷贝到 OpenHarmony 代码库中适合的地位, 如下将 iperf3 增加到 /third_party 目录下。

须要留神的是非内核态的库不能增加到内核的目录下，不然编译和调试过程中相干的头文件可能找不到。在 /vendor/ 厂商名 / 产品型号 /config.json 中的某一子系统下增加组件。

在 /build/lite/components/ 子系统名.json 中增加组件，如下：

编写配置 BUILD.gn

移植的 iperf3 代码目录下须要提供一个 gn 文件，指明须要编译的代码。此文件能够通过 import 组件模板函数。一方面，很多援用到的头文件须要一一增加到零碎 BUILD.GN 中去，import 组件模板函数能够省去很多麻烦；另一方面，头文件有多个，最终还很难确定是哪一个，应用系统配置好的组件模板函数，能够主动匹配。

程序启动入口：将三方库增加到 shell 命令

1) 内核态的 shell 性能不合乎 POSIX 规范，仅供调试应用，本文特记录下其增加命令的办法，此办法分为动态和动静两种形式, 增加形式如下：
① 命令源代码蕴含如下头文件

#include "shell.h"
#include "shcmd.h"

② 动态注册命令形式

第一步：调用 SHELLCMD_ENTRY(l, cmdType, cmdKey, paraNum, cmdHook)，在源文件最初减少这个调用即可。

第二步：在链接选项中增加链接该新增命令项参数。
即在 kernel/liteos_a/tools/build/mk/liteos_tables_ldflags.mk 中减少相应选项，SHELLCMD_ENTRY 的第一个参数前加 -u。

此办法增加的 shell, 在代码编译阶段就已编译进去了，其实现原理是利用了编译器的 section 个性(也是代码模块化的重要伎俩)，将所有 shell 命令相干性能都放在一段间断的地址空间，将 SHELLCMD_ENTRY 宏一层层开展，即可失去上面原型。

LOS_HAL_TABLE_BEGIN(g_shellcmd, shellcmd); // 段的起始 tagLOS_HAL_TABLE_END(g_shellcmdEnd, shellcmd); // 段的完结 tagSHELLCMD_ENTRY(l, cmdType, cmdKey, paraNum, cmdHook)

如下是编译后生成的 map 文件中 shell 段的局部，能够察看到曾经通过此办法退出的 shell 命令。

③ 动静注册命令方
式此类形式是在代码运行阶段动静的注册，osCmdReg 自身是一个函数，在命令初始化的源代码减少此函数调用。

UINT32 osCmdReg(CmdT ype cmdType, CHAR *cmdKey, UINT32 paraNum, CmdCallBackFunc cmdProc)

函数原型在 /kernel/liteos_a/shell/full/src/base/shcmd.c 能够找到，基本原理是将动静注册的 shell 命令退出到动静 shell 命令链表空间。

2）用户态的 shell 不必手动增加
增加指标的形式为 executable，将程序下载到指标板上，在 /bin 目录下找到可执行的文件，只有在串口助手中输出 ./bin/ 可执行文件名，内核即可动静加载可执行的文件（或者输出 exec /bin/ 可执行文件名）。

应用 iperf3 测试时必须将一台主机设置为客户端，一台主机设置为服务器。在 Linux 环境或者 Windows 或者 OpenHarmony shell 交互窗口输出 iperf3 - h 能够获取 iperf3 的帮忙信息。以下介绍几种常见的应用形式:

iperf3 测试 TCP
在默认的状况下，iperf3 客户端与指定的监听 5201 端口的 iperf3 服务器建设一个 TCP 会话。

服务端：iperf3 - s 客户端：iperf3 -c 服务器 IP   (默认测试 10 秒)，应用 t 来设置测试工夫，单位是秒。例如：iperf3 -c 192.168.99.74 -t 20

运行后果如下：

iperf3 测试 UDP
iperf3 测试 UDP 性能时，客户端能够指定 UDP 数据流的速率。客户端发送数据时，将依据客户端提供的速率计算数据报发送之间的时延。

客户端还能够指定发送数据报的大小。每个发送的数据报蕴含一个 ID 号，用来惟一标识报文，服务器端依据该 ID 号来确定数据报失落和乱序。

当把 UDP 报文大小设置能够将整个报文放入 IP 层的包 (packet) 内时，那么 UDP 所测得的报文失落数据即为 IP 层包的失落数据，这提供了一个无效的测试包失落状况的办法。

数据报传输提早抖动 (Jitter) 的测试由服务器端实现，客户发送的报文数据蕴含有发送工夫戳，服务器端依据该工夫信息和接管到报文的工夫戳来计算传输提早抖动。传输提早抖动反映传输过程中是否平滑。因为它是一个相对值，所以并不需要客户端和服务器端工夫同步。测试过程如下：

服务端：iperf3 -s -p 6868（设定服务端监听 6868 端口）Liteos_A shell 客户端：./bin/iperf3 -c 172.17.5.159 -p 6868 -u -b 100M

测试后果：

Jitter（延时变动）：用 iperf3 UDP 测试来量度
数据报失落：用 iperf3 UDP 测试来量度 -
带宽：通过 TCP 测试来量度

反向带宽测试
服务端应用的命令不变，客户端须要加上参数 -R，在帮忙信息中，能够看到 - R 的信息是 run in reverse mode (server sends, client receives)
```
服务端：iperf3 -s -p 6868 客户端：./bin/iperf3 -c 172.17.5.159 -p 6868 -u -b 100M -R
```
测试后果如下：

同步双向带宽测试
客户端加上命令参数 -bidir

服务端：iperf3 -s -p 6868 客户端：./bin/iperf3 -c 172.17.5.159 -p 6868 -u -b 100M -bidir

测试后果如下：

Hi3516 有三种下载程序的形式：串口、USB、网口转 USB。举荐应用 USB 来下载程序，应用串口来调试程序。
DevEco Device Tool 工具应用 USB 烧录 Hi3516DV300 镜像时失败，怎么解决？

解决措施：
呈现这个问题，次要是因为开发者将 Device Tool 工具装置在零碎盘符，在烧录大文件时会因为没有权限导致失败，能够依据以下操作解决：
● 在 Windows 平台找到装置目录，如图。鼠标右键，选中属性。
● 顺次操作，步骤 5 将红框中两个选项都勾选上。

Hi3516 如果携带操作系统是反对 Linux 内核的 OpenHarmony，第一次下载时，须要格式化，下载实现后，系统启动到 boot，就不会疏导整个零碎应用程序，这时须要点击如下菜单，而后从新拔插 USB 能力进入整个零碎。

在编写.gn 文件时，如果三方组件为 executable，那么第三方库代码中须要有惟一个入口 main 函数，最终生成一个可执行的命令。
iperf 有大版本 1，2，3，目前最新的是 iperf3，不同的版本间命令参数不同，工作机制有所不同，所以在测试时，服务端和客户端要求应用雷同的大版本。例如 iperf3 服务端不反对 iperf 的 -u,- 命令。
在应用 iperf3 进行测试过程中，须要敞开防火墙，不然可能不能进行失常测试，能够提前应用 ping 测试一下网络是否已通。
公司网络端的管制也会对测试造成影响，如果测试中发现发送和接管到的数据始终是 0，则可能是网络管制端进行了管制，在拔掉外网络的状况，测试进去的后果就会很稳固。
Hi3516 主板作为服务端，输出 iperf3 -s，而后在 PC 机上启动客户端进行测试，发现基本不能进行失常测试，起因也是公司网络管制导致，解决办法是将要测试的两个网络接口，接到同一交换机下，而后拔掉外网的网线，能够进行失常测试；或者须要 IT 开发权限，当然如果不是在公司特定网络环境下，这个景象是不会呈现的。
Hi3516 须要设置网络能力进行测试，能够应用命令 ifconfig 来设置，例如：ifconfig eth0 172.17.5.253 netmask 255.255.254.0 gateway 172.17.4.1
MSS 在 OpenHarmony 的底层 LWIP 不反对，在 iperf_connect 函数中调用 getsockopt(test->ctrl_sck, IPPROTO_TCP, TCP_MAXSEG, &opt, &len)，会通过零碎调用达到 kernel 层中的 /kernel/liteos_a/compat/posix/src/socket.c, 最终走到底层 LWIP 的 lwip_getsockopt_impl 接口，在 level IPPROTO_TCP 下，对于分支 TCP_MAXSEG，没有实现，解决办法是先屏蔽 iperf3 对此处的操作。同样在调用 setsockopt(s, SOL_SOCKET, SO_SNDBUF, &opt, sizeof(opt))时，SO_SNDBUF 分支在 LWIP 也未实现，先屏蔽此处，将发送缓冲区设置成和接收缓冲区同样的大小。
Liteos_A 未实现延时删除，所以调用 unlink 时会出错，目前解决是先屏蔽此处。
Liteos_A 对 fprintf 的实现也不如 Linux，Windows 好，所以对 help 命令输入到 stdout 上，长字串显示不进去，解决办法是应用 fputs 替换 fprintf。

本文从 iperf3 的工作原理、移植过程、应用形式、注意事项四个方面介绍了将 iperf3 移植到反对 Liteos_A 内核的 OpenHarmony 操作系统中的办法，心愿本篇文章对开发者有所帮忙。

对于 OpenHarmony 内核的内容，之前我还介绍了内核对象队列的算法、OpenHarmony LiteOS- M 内核事件的运作机制，以及内核 IPC 机制数据结构，感兴趣的读者能够点击浏览：
《OpenHarmony——内核对象队列之算法详解（上）》、
《OpenHarmony——内核对象队列之算法详解（下）》、
《OpenHarmony——内核对象事件之源码详解》、
[《OpenHarmony——内核 IPC 机制数据结构解析》。
](https://mp.weixin.qq.com/s?__…)

正文完