阅读说明：本技术 一种嵌入式系统内存零拷贝的方法及装置 (Method and device for zero copy of memory of embedded system ) 是由 许井泉 黄永佳 周进 于 2020-06-30 设计创作，主要内容包括：本申请公开了一种嵌入式系统内存零拷贝的方法,包括如下步骤。步骤S10：采用统一数据块格式,包括标准头部、扩展头部和预留空间。步骤S20：模块A按照统一数据块格式为数据Z分配内存,并配置mem_msg字段；同时在统一数据块格式的对应头部位置写入数据Z。步骤S30：模块A扩展pbuf的数据结构,增加指向以太网头部以及内存分配和释放字段的指针。步骤S40：模块A基于扩展后的pbuf数据结构处理数据Z,在pbuf释放函数中增加pkt_msg指针所指向的mem_msg字段中的释放函数指针。步骤S50：模块B读取内存分配和释放字段,调用其中的释放函数指针所指向的内存释放函数来释放数据Z占用的内存。本申请对内存分配和释放、数据零拷贝传递进行了优化。(The application discloses a memory zero-copy method of an embedded system, which comprises the following steps. Step S10: and adopting a uniform data block format, wherein the uniform data block format comprises a standard header, an extended header and a reserved space. Step S20: the module A allocates memory for the data Z according to the uniform data block format and configures a mem _ msg field; while writing data Z at the corresponding header location of the unified data block format. Step S30: module a extends the data structure of pbuf and adds pointers to the ethernet header and memory allocation and release fields. Step S40: module a processes data Z based on the extended pbuf data structure, adding in the pbuf release function a release function pointer in the mem _ msg field to which the pkt _ msg pointer points. Step S50: and the module B reads the memory allocation and release field and calls the memory release function pointed by the release function pointer to release the memory occupied by the data Z. The method and the device optimize memory allocation and release and data zero copy transfer.)

一种嵌入式系统内存零拷贝的方法及装置

技术领域

本申请涉及一种嵌入式系统(embedded system)的内存分配和释放管理方法。

背景技术

基于RTOS(real-time operating system，实时操作系统)的嵌入式系统中，可能存在多种类型的内部存储器，比如RAM(random-access memory，随机存取存储器)、ROM(read-only memory，只读存储器)、以及特定的内存池(memory pool)。本申请中将这些嵌入式系统中的内部存储器统称为内存。同时为了适应模块使用的特殊场景，还可能针对模块自行定义内存分配和释放的方式。对于RTOS系统，任务的调度一般采用线程(thread)的方式，内存对所有线程是共享的，所以线程之间的消息交互经常会采用共享内存的方式，这就带来了内存分配和释放的管理问题，如果处理不当，很容易带来内存泄露，导致系统出现故障。此外，嵌入式系统中的内存资源有限，为了减少系统开销需要尽可能减少拷贝。

以无线网络路由器为例，设备需要处理各个接口的数据包，包括WiFi接口的数据包、以太网接口的数据包、或者是3G、4G移动通讯模块的数据包，以及内部应用的数据包。不同的数据来源可能对应不同的内存分配模式，而对于TCP/IP协议中，每层IP数据包的处理还需要尽可能地减少拷贝，以免带来性能的损失。

现有的技术方案更多的集中在提高内存的分配效率上，比如采用内存池的设计方式提高访问效率，而没有从系统的角度提出优化解决方案。

发明内容

本申请所要解决的技术问题是提供一种在嵌入式系统的不同端口具有不同内存分配形式的条件下，实现内存在TCP/IP各层的不同接口之间的零拷贝的数据传递和内存释放的方法。本申请适用于共享内存的多线程调度系统中内存的分配和释放管理。

为解决上述技术问题，本申请提出了一种嵌入式系统内存零拷贝的方法，包括如下步骤。步骤S10：嵌入式系统中采用统一数据块格式，包括标准头部、扩展头部和预留空间；标准头部包括以太网头部、IP头部、TCP或UDP头部；扩展头部用来替换嵌入式系统的不同接口采用的协议的头部；预留空间预留给内存分配和释放字段即mem_msg字段。步骤S20：模块A按照统一数据块格式为数据Z分配内存，并根据内存分配情况配置mem_msg字段的数据结构，其中包括指向内存释放函数和指向内存释放地址的指针；然后把mem_msg字段写入所述预留空间；同时在统一数据块格式的对应头部位置写入数据Z。步骤S30：模块A扩展pbuf数据结构，在pbuf数据结构中增加指向以太网头部的pkt_mac指针以及指向mem_msg字段的pkt_msg指针。步骤S40：模块A基于扩展后的pbuf数据结构处理数据Z，将数据Z挂载到pbuf数据结构的payload字段；还在pbuf释放函数中增加pkt_msg指针所指向的mem_msg字段中的释放函数指针。步骤S50：对于转发到模块B的数据Z，模块B读取mem_msg字段，调用其中的释放函数指针所指向的内存释放函数来释放数据Z占用的内存。上述方法首先对TCP/IP各种协议的数据包分析，采用统一数据块的扩展头部充分预留包头空间，解决数据包经过各层以及各接口可能带来的数据修改和填充，而充分预留的空间也避免了后续的内存拷贝。同时针对RTOS系统中存在的多种内存分配形式，在统一数据块中设计内存分配和释放字段用于记录内存的释放指针，灵活而方便地实现了谁分配谁释放的原则，避免内存的泄露。

进一步地，所述步骤S10中，所述统一数据块格式自前向后依次包括扩展头部、以太网头部、IP头部、TCP或UDP头部、净荷。这是统一数据块的数据结构的优选示例。

进一步地，所述步骤S10中，所述扩展头部的长度大于或等于嵌入式系统的不同接口采用的协议的头部长度中的最大长度。这样才能用扩展头部代替各种协议的头部，从而统一不同接口的数据包的长度和格式。

进一步地，所述步骤S10中，所述嵌入式系统的不同接口采用的协议包括RNDIS协议、WiFi协议、ECM协议的任意一种或多种。这里列举了几种常见的协议作为示例。

进一步地，所述步骤S20中，所述mem_msg字段的数据结构中包括：释放函数指针free，用来指向内存释放函数；数据块头部指针mem_hdr，用来指向内存分配的首地址，也就是指向内存释放的首地址；数据块长度men_len，用来记录了每个统一数据块的长度。这是内存分配和释放字段所包含内容的优选示例。

进一步地，所述步骤S20中，如果数据Z是IP数据包，则从统一数据块格式的IP头部位置开始写入数据Z。如果数据Z是以太网数据包，则从统一数据块格式的以太网头部位置开始写入数据Z。如果数据Z是不同协议的接口的数据块，则从统一数据块格式的扩展头部位置开始写入数据Z。这里给出了不同接口的数据包在统一数据块格式中的输入写入的开始位置。

进一步地，所述步骤S20中，所述mem_msg字段的大小固定，由内存分配模块负责写入。这是内存分配和释放消息字段的长度和写入主体的优选示例。

进一步地，所述步骤S40中，修改后的pbuf释放函数执行后，不仅用来释放扩展后的pbuf数据结构，还同时执行释放函数指针所指向的内存释放函数而实现数据Z的内存空间的释放。这是对步骤S40中修改pbuf释放函数的具体功能实现的说明。

进一步地，所述步骤S40中，如果扩展后的pbuf数据结构中的pkt_msg指针未设置内容，那么执行修改后的pbuf释放函数只用来释放扩展后的pbuf数据结构。如果扩展后的pbuf数据结构中的pkt_msg变量已设置内容，那么执行修改后的pbuf释放函数就在释放扩展后的pbuf数据结构的同时，还释放数据Z所分配的内存空间。这是根据pkt_msg指针是否设置有内容而给出的不同处理方式。

本申请还提出了一种嵌入式系统内存零拷贝的装置，包括接口模块数据块构建单元、接口模块内存分配单元、扩展单元、TCP/IP协议栈处理单元和接口模块内存释放单元。所述接口模块数据块构建单元用来构建统一数据块格式；所述统一数据块格式包括标准头部、扩展头部和预留空间；标准头部包括以太网头部、IP头部、TCP或UDP头部；扩展头部用来替换嵌入式系统的不同接口采用的协议的头部；预留空间预留给内存分配和释放字段即mem_msg字段。所述接口模块内存分配单元用来按照统一数据块格式为数据Z分配内存，并根据内存分配情况配置mem_msg字段的数据结构，其中包括指向内存释放函数和指向内存释放地址的指针；然后把mem_msg字段写入所述预留空间；所述接口模块内存分配还用来在统一数据块格式的对应头部位置写入数据Z。所述扩展单元用来扩展pbuf数据结构，在pbuf数据结构中增加指向以太网头部的pkt_mac指针以及指向mem_msg字段的pkt_msg指针。所述TCP/IP协议栈处理单元用来基于扩展后的pbuf数据结构处理数据Z，将数据Z挂载到pbuf数据结构的payload字段；还在pbuf释放函数中增加pkt_msg指针所指向的mem_msg字段中的释放函数指针。所述接口模块内存释放单元用来对于由所述TCP/IP协议栈处理单元转发到其他模块的数据Z，读取数据Z的统一数据块格式中的mem_msg字段，调用其中的释放函数指针所指向的内存释放函数来释放数据Z占用的内存。上述系统对内存分配和释放、数据零拷贝传递进行了优化。

本申请取得的技术效果是：相比以往的内存优化方案，结合内存的分配和释放以及内存的传递，提出了一套较为全面的优化方案。第一，设计方案的实现，并不对现有的数据流程和设计框架有所变动，对现有的RTOS多线程系统，可以做到较小的代码改动实现本方案。第二，特别适合具备TCP/IP协议的RTOS处理系统，可以非常有效地避免数据包在TCP/IP各层之间的拷贝。第三，以高效简洁的方式解决嵌入式系统内存分配释放中内存泄露风险，符合嵌入式系统中内存分配谁分配谁负责的原则，避免潜在的内存泄露问题。

附图说明

图1是嵌入式网络设备使用的RTOS系统的典型实现框图。

图2是无线路由器基于LwIP协议栈的RTOS系统的典型实现框图。

图3是IP数据包的数据格式简化示意图。

图4是添加了以太网头部的IP数据包的数据格式简化示意图。

图5是RNDIS接口的数据块的数据格式简化示意图。

图6是WiFi接口的数据块的数据格式简化示意图。

图7是本申请提出的嵌入式系统内存零拷贝的方法的流程图。

图8是本申请提出的统一数据块的数据格式简化示意图。

图9是步骤S50中数据Z在不同模块之间流转的过程的示意图。

图10是本申请提出的嵌入式系统内存零拷贝的装置的结构示意图。

图中附图标记说明：10为接口模块数据块构建单元；20为接口模块内存分配单元；30为扩展单元；40为TCP/IP协议栈处理单元；50为接口模块内存释放单元。

具体实施方式

请参阅图1，这是嵌入式网络设备使用的RTOS系统的典型实现框图。嵌入式网络设备中一般具有多个LAN(Local Area Network，局域网)接口以及至少一个WAN(Wide AreaNetwork，广域网)接口。LAN接口简称为LAN口，WAN接口简称为WAN口。这些LAN口通过RTOS系统中的报文处理主线程共享单个或多个WAN接口接入Internet网络。每个LAN口可用于连接一台接入设备。WAN口可用于连接网络出口设备。如图1所示，基于RTOS系统的报文处理线程可能会有多个，接口也可能有多种，每个接口可能对应不同的接入协议。

无线路由器是一种典型的嵌入式系统，一般采用RTOS系统，配合嵌入式系统专用的TCP/IP协议栈实现。lwIP(lightweight IP，轻量IP)是一个开源的TCP/IP协议栈，在嵌入式系统开发中得到广泛应用。请参阅图2，这是无线路由器基于LwIP协议栈的RTOS系统的典型实现框图，所述RTOS系统例如为嵌入式领域广泛使用的ThreadX。无线路由器例如以单芯片的方案实现3G、4G、5G等的移动通讯数据接入WAN口；RNDIS(Remote Network DriverInterface Specification，远程网络驱动接口规范)/ECM(Ethernet Control Model，以太网控制模型)接口、WiFi接口作为内网接入的LAN口，允许所接入设备(例如PC主机等)共享移动通讯数据流量接入互联网。这是通用的无线路由器设备的一种具体实现，下面将以该无线路由器为示例进行阐述，但是本申请的原理可以扩展应用于到涉及内存分配管理的其他嵌入式系统，而并不限制为无线路由器设备。

如图2所示，以无线路由器为示例的嵌入式系统对数据的处理过程分为上行和下行两条路径。对于上行通道，数据流向为：PC主机->LAN口(WiFi接口、或RNDIS/ECM接口)->LwIP报文处理主线程->WAN口(3G/4G接口)。对于下行通道，数据流向为：WAN口(3G/4G接口)->LwIP报文处理主线程->LAN口(WiFi接口、或RNDIS/ECM接口)->PC主机。上下行处理的数据主要是IP数据包，但是对于不同的数据接口又有区别，如WAN口直接收发的就是IP数据包，而WiFi接口(LAN口)收发的则是有WiFi协议头部和以太网头部的IP数据包，对于RNDIS接口收发的则是有RNDIS协议头部和以太网头部的IP数据包。另外，各个接口收发数据都有自己的内存使用方式，比如WAN口处理下行数据的时候，3G/4G模块会按照自己的方式分配内存，然后发送到LwIP报文处理主线程，各个LAN口对内存分配的处理方式也与此类似。

从模块解耦合的设计角度出发，模块和模块之间进行数据传递的时候，采用内存拷贝的方式是最合理的，这样模块和模块之间没有数据耦合，也不存在谁分配谁释放的问题，各层按照各层的需求添加新的头部，但是这种设计最大的缺陷就是带来巨大的内存拷贝开销以及性能的损失。所以如何解决数据在各个模块之间最小开销的传递，以及避免内存泄露的问题，成为设计的关键。

图2所示的无线路由器设备中，各个数据接口收发的数据块具有不同形式。

请参阅图3，IP数据包的格式依次包括IP头部、TCP或UDP头部、净荷(payload)。对于WAN口是3G/4G接口的，数据块通常为IP数据包格式。

请参阅图4，添加了以太网头部的IP数据包(即以太网数据包)的格式依次包括以太网头部、IP头部、TCP或UDP头部、净荷等。

请参阅图5，如果LAN口是RNDIS接口，则收发的数据块格式依次包括RNDIS协议头部、以太网头部、IP头部、TCP或UDP头部、净荷等。

请参阅图6，如果LAN口是WiFi接口，则收发的数据块格式依次包括WiFi协议头部、以太网头部、IP头部、TCP或UDP头部、净荷等。

从图3至图6可以看出，各个接口收发的数据块的形式并不一致，有共同的部分，也有不同的部分。但是有一点是明确的，即不同的协议头部长度是可预估的。

请参阅图7，本申请提出的嵌入式系统内存零拷贝的方法包括如下步骤。

步骤S10：采用统一数据块格式，其中包括标准头部、扩展头部和预留空间。标准头部自前向后依次包括以太网头部、IP头部、TCP或UDP头部。扩展头部在标准头部之前，扩展头部用来替换嵌入式系统的不同接口采用的协议头部，比如RNDIS协议头部、WiFi协议头部、ECM接口协议的头部或者其他协议头部，扩展头部的长度设计为大于或等于一个或多个所需协议头部中的最大长度。预留空间在扩展头部之前，用来预留给内存分配和释放字段。所述内存分配和释放字段命名为mem_msg，实现自适应的内存释放要求。

请参阅图8，本申请提出的统一数据块格式依次包括预留空间、扩展头部、以太网头部、IP头部、TCP或UDP头部、净荷等。其中的以太网头部、IP头部、TCP或UDP头部合称为标准头部。

步骤S20：对于任意接口的数据包(以下称为数据Z)，模块A按照统一的数据块格式分配内存，并根据内存分配情况配置mem_msg字段的数据结构，主要是设置内存释放函数和内存释放地址。然后模块A把mem_msg字段写入所述预留空间，同时在统一的数据块格式的对应的头部位置写入数据Z的数据。例如对于图4所示的以太网数据包，则从统一的数据块格式的以太网头部位置开始写入以太网数据。又如对于图3所示的IP数据包，则从统一的数据块格式的IP头部位置开始写入IP数据。再如对于图5或图6所示的不同接口的数据块，则从统一的数据块格式的扩展头部位置开始写入数据块。

作为一个示例，mem_msg字段的数据结构设计如下，其中/*到*/之间的内容为注释说明。

上述mem_msg字段的大小固定，便于统一数据块格式扩展，其中最关键的参数是释放函数指针free，用来指向内存释放函数，由内存分配模块负责写入。数据块头部指针mem_hdr用来指向内存分配的首地址，也就是指向内存释放的首地址。数据块长度men_len记录了每个统一数据块的长度。

步骤S30：模块A扩展pbuf的数据结构，增加指向以太网头部的指针以及指向内存分配和释放字段mem_msg的指针，以加快以太网模块和内存释放模块的处理。

pbuf数据结构是LwIP协议栈中用来组织TCP/IP数据包的数据结构。一个完整的TCP/IP数据包可以由一个pbuf数据结构实现、或者由多个pbuf数据结构组成的pbuf链(pbuf chain)来实现。对于其他的嵌入式TCP/IP协议栈，有类似的数据结构来组织TCP/IP数据包。本申请以LwIP协议栈的pbuf数据结构为例进行说明，相同原理也适用于其他TCP/IP协议栈。

本申请提出的扩展后的pbuf数据结构简单描述如下，其中/*到*/之间的内容为注释说明。

上述pbuf数据结构中，pkt_mac变量是本申请新增加的，是指向以太网头部位置的指针。pkt_msg变量也是本申请新增加的，是指向内存分配和释放字段mem_msg位置的指针。

步骤S40：模块A基于扩展后的pbuf数据结构处理采用统一的数据块格式的数据Z，将采用统一的数据块格式的数据Z挂载到pbuf数据结构的payload字段。模块A还在pbuf释放函数中增加pkt_msg变量所指向的内存分配和释放字段mem_msg中的释放函数指针free。传统的pbuf释放函数执行后，只用来释放pbuf数据结构。本申请修改后的pbuf释放函数执行后，不仅用来释放扩展后的pbuf数据结构，还同时执行释放函数指针free所指向的内存释放函数而实现数据Z的内存空间的释放。这样就把数据Z在TCP/IP协议处理过程中涉及到的内存释放操作无缝嵌入到pbuf数据结构的释放操作过程中。

具体而言，如果扩展后的pbuf数据结构中的pkt_msg变量未设置，那么执行pbuf释放函数只用来释放扩展后的pbuf数据结构。如果扩展后的pbuf数据结构中的pkt_msg变量有设置，那么执行pbuf释放函数就在释放扩展后的pbuf数据结构的同时，还释放数据Z所分配的内存。

步骤S50：对于转发到模块B的采用统一的数据块格式的数据Z，模块B读取统一的数据块格式的内存分配和释放字段mem_msg，调用其中的释放函数指针free所指向的内存释放函数来释放数据Z占用的内存。

所述步骤S10至步骤S40都是在TCP/IP协议栈内部进行数据处理，例如是采用LwIP协议栈来处理。在步骤S40执行完毕之后，数据Z有两种可能的情形。情形一是数据Z已经在TCP/IP协议栈内部处理完毕。情形二是数据Z要离开TCP/IP协议栈由其他模块进行处理。所述步骤S50描述了情形二，此时模块B仍然可以基于统一的数据块格式中的指向内存释放函数的指针来调用内存释放函数释放数据Z的内存空间。图9示意性地描述了步骤S20和S50所示的数据Z在不同模块之间进行传递的过程。

请参阅图10，本申请提出的嵌入式系统内存零拷贝的装置包括接口模块数据构建单元10、接口模块内存分配单元20、扩展单元30、TCP/IP协议栈处理单元40以及接口模块内存释放单元50。

所述接口模块数据块构建单元10用来构建统一数据块格式。所述统一数据块格式包括标准头部、扩展头部和预留空间。标准头部包括以太网头部、IP头部、TCP或UDP头部。扩展头部用来替换嵌入式系统的不同接口采用的协议的头部。预留空间预留给内存分配和释放字段即mem_msg字段。

所述接口模块内存分配单元20用来按照统一数据块格式为数据Z分配内存，并根据内存分配情况配置mem_msg字段的数据结构，其中包括指向内存释放函数和指向内存释放地址的指针；然后把mem_msg字段写入所述预留空间。所述接口模块内存分配20还用来在统一数据块格式的对应头部位置写入数据Z。

所述扩展单元30用来扩展pbuf数据结构，在pbuf数据结构中增加指向以太网头部的pkt_mac指针以及指向mem_msg字段的pkt_msg指针。

所述TCP/IP协议栈处理单元40用来基于扩展后的pbuf数据结构处理数据Z，将数据Z挂载到pbuf数据结构的payload字段；还在pbuf释放函数中增加pkt_msg指针所指向的mem_msg字段中的释放函数指针。

所述接口模块内存释放单元50用来对于由所述TCP/IP协议栈处理单元40转发到其他模块的数据Z，读取数据Z的统一数据块格式中的mem_msg字段，调用其中的释放函数指针所指向的内存释放函数来释放数据Z占用的内存。

与现有的嵌入式系统的内存分配和管理方法相比，本申请具有如下有益效果。

第一，嵌入式系统的每一个数据接口都按照统一的数据格式进行数据块的预分配，同时结合LwIP协议栈中的pbuf数据结构来记录指向IP数据包的净荷的指针，以IP头部的数据位置为基础，各层需要处理哪个头部的数据只需要头部进行相对偏移即可，不用重新分配内存去添加头部，也不用担心内存空间不够或者内存地址错误。这样就以统一数据块的形式解决了内存传递过程中的数据拷贝问题。

第二，本申请在新增的mem_msg字段中记录了内存释放函数的指针，便于其他模块根据该指针调用内存释放函数，从而自适应释放内存。以图9为例，模块B最终释放数据块的时候，调用模块A设置的内存释放函数进行内存释放，模块B并不需要关心该内存的具体分配形式，不管是RAM内存分配、还是ROM内存分配、或者是内存池的分配，以及其他形式的内存分配，只要模块A设置了对应的内存释放函数，填写了正确的mem_msg字段，模块B都能正确释放该内存。这种处理方式真正实现了系统设计中谁分配谁释放的原则，避免潜在的内存泄露问题。

第三，数据块从模块A初始分配、多模块的处理流程，到最终的模块B的释放，做到了零拷贝的数据流转，只需要把数据块指针带到下一个处理模块即可，极大的提高了整个系统的处理性能。

以上仅为本申请的优选实施例，并不用于限定本申请。对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。