阅读说明：本技术 一种嵌入式系统内存零拷贝的方法及装置 (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.)

1. A method for zero copy of memory of embedded system is characterized by comprising the following steps;

step S10: the embedded system adopts a uniform data block format and comprises a standard head, an extended head and a reserved space; the standard header comprises an ethernet header, an IP header, a TCP or UDP header; the extension header is used for replacing a header of a protocol adopted by a different interface of the embedded system; reserving a reserved space for a memory allocation and release field, namely a mem _ msg field;

step S20: the module A allocates a memory for the data Z according to a uniform data block format, and configures a data structure of a mem _ msg field according to the memory allocation condition, wherein the data structure comprises a pointer pointing to a memory release function and a pointer pointing to a memory release address; then writing the mem _ msg field into the reserved space; simultaneously writing data Z in the corresponding head position of the unified data block format;

step S30: the module A expands a pbuf data structure, and adds a pkt _ mac pointer pointing to the head of the Ethernet and a pkt _ msg pointer pointing to a mem _ msg field in the pbuf data structure;

step S40: the module A processes data Z based on the extended pbuf data structure, and mounts the data Z to a payload field of the pbuf data structure; a release function pointer in the mem _ msg field pointed by the pkt _ msg pointer is also added to the pbuf release function;

step S50: for data Z forwarded to the module B, the module B reads the mem _ msg field and calls a memory release function pointed by the release function pointer to release the memory occupied by the data Z.

2. The method for memory zero copy of embedded system as claimed in claim 1, wherein in step S10, the uniform data block format comprises an extension header, an ethernet header, an IP header, a TCP or UDP header, and a payload in sequence from front to back.

3. The method for zero-copy memory of an embedded system as claimed in claim 1, wherein in step S10, the length of the extended header is greater than or equal to the maximum length among the header lengths of the protocols used by the different interfaces of the embedded system.

4. The method of zero copy in memory of embedded system as claimed in claim 1, wherein in step S10, the protocols adopted by different interfaces of the embedded system include any one or more of RNDIS protocol, WiFi protocol, and ECM protocol.

5. The method for zero-copying memory of an embedded system as claimed in claim 1, wherein in step S20, the data structure of the mem _ msg field includes:

a release function pointer free for pointing to the memory release function;

a data block header pointer mem _ hdr, which is used to point to the first address allocated to the memory, that is, to point to the first address released from the memory;

data block length men _ len, which is used to record the length of each uniform data block.

6. The method for zero-copy memory of embedded system as claimed in claim 1, wherein in step S20, if Z is an IP packet, Z is written from the IP header position of the uniform data block format;

if the data Z is an Ethernet data packet, writing the data Z from the Ethernet head position of the uniform data block format;

if the data Z is a data block of an interface of a different protocol, the data Z is written starting from an extended header position of the unified data block format.

7. The embedded system memory zero-copy method as claimed in claim 1, wherein in step S20, the size of the mem _ msg field is fixed.

8. The method for zero-copy of memory in an embedded system as claimed in claim 1, wherein in step S40, after the modified pbuf release function is executed, the modified pbuf release function is used to release not only the extended pbuf data structure, but also the memory release function pointed by the release function pointer is executed at the same time to release the memory space of the data Z.

9. The method according to claim 1, wherein in step S40, if the pkt _ msg pointer in the extended pbuf data structure is not set, the modified pbuf release function is executed to release only the extended pbuf data structure;

if the pkt _ msg variable in the extended pbuf data structure has set contents, then executing the modified pbuf release function releases the memory space allocated by data Z while releasing the extended pbuf data structure.

10. A device for zero copy of memory of an embedded system is characterized by comprising an interface module data block construction unit, an interface module memory allocation unit, an extension unit, a TCP/IP protocol stack processing unit and an interface module memory release unit;

the interface module data block construction unit is used for constructing a uniform data block format; the unified data block format comprises a standard header, an extended header and a reserved space; the standard header comprises an ethernet header, an IP header, a TCP or UDP header; the extension header is used for replacing a header of a protocol adopted by a different interface of the embedded system; reserving a reserved space for a memory allocation and release field, namely a mem _ msg field;

the interface module memory allocation unit is used for allocating memory for data Z according to a uniform data block format and configuring a data structure of a mem _ msg field according to memory allocation conditions, wherein the data structure comprises a pointer pointing to a memory release function and a pointer pointing to a memory release address; then writing the mem _ msg field into the reserved space; the interface module memory allocation is also used for writing data Z in the corresponding head position of the unified data block format;

the extension unit is used for extending the pbuf data structure, and adding a pkt _ mac pointer pointing to the head of the Ethernet and a pkt _ msg pointer pointing to the mem _ msg field in the pbuf data structure;

the TCP/IP protocol stack processing unit is used for processing data Z based on the extended pbuf data structure and mounting the data Z to a payload field of the pbuf data structure; a release function pointer in the mem _ msg field pointed by the pkt _ msg pointer is also added to the pbuf release function;

the interface module memory release unit is used for reading a mem _ msg field in a unified data block format of data Z for the data Z forwarded to other modules by the TCP/IP protocol stack processing unit, and calling a memory release function pointed by a release function pointer in the mem _ msg field to release a memory occupied by the data Z.

Technical Field

The present application relates to a memory allocation and release management method for an embedded system (embedded system).

Background

In an RTOS (real-time operating system) based embedded system, there may be various types of internal memories, such as a RAM (random-access memory), a ROM (read-only memory), and a specific memory pool (memory pool). The internal memories in these embedded systems are collectively referred to herein as memory. Meanwhile, in order to adapt to a special scene of the module, the memory allocation and release modes can be defined for the module. For an RTOS system, task scheduling generally adopts a thread (thread) mode, and a memory is shared by all threads, so message interaction between the threads often adopts a memory sharing mode, which brings management problems of memory allocation and release, and if processing is not proper, memory leakage is easily caused, resulting in system failure. In addition, the embedded system has limited memory resources, and it is necessary to reduce the number of copies as much as possible in order to reduce the system overhead.

Taking a wireless network router as an example, the device needs to process data packets of each interface, including data packets of a WiFi interface, data packets of an ethernet interface, or data packets of 3G and 4G mobile communication modules, and data packets of internal applications. Different data sources may correspond to different memory allocation patterns, and for the TCP/IP protocol, the processing of IP packets at each layer needs to reduce the copy number as much as possible to avoid performance loss.

The existing technical solutions focus more on improving the allocation efficiency of the memory, for example, a design mode of a memory pool is adopted to improve the access efficiency, and an optimization solution is not proposed from the perspective of the system.

Disclosure of Invention

The technical problem to be solved by the present application is to provide a method for implementing zero-copy data transfer and memory release between different interfaces with TCP/IP layers in the embedded system under the condition that different ports of the embedded system have different memory allocation forms. The method and the device are suitable for memory allocation and release management in the multi-thread scheduling system of the shared memory.

In order to solve the above technical problem, the present application provides a method for zero-copy of an embedded system memory, which includes the following steps. Step S10: the embedded system adopts a uniform data block format and comprises a standard head, an extended head and a reserved space; the standard header comprises an ethernet header, an IP header, a TCP or UDP header; the extension header is used for replacing a header of a protocol adopted by a different interface of the embedded system; the reserved space is reserved for a memory allocation and release field, namely a mem _ msg field. Step S20: the module A allocates a memory for the data Z according to a uniform data block format, and configures a data structure of a mem _ msg field according to the memory allocation condition, wherein the data structure comprises a pointer pointing to a memory release function and a pointer pointing to a memory release address; then writing the mem _ msg field into the reserved space; while writing data Z at the corresponding header location of the unified data block format. Step S30: module a extends the pbuf data structure, adding a pkt _ mac pointer to the ethernet header and a pkt _ msg pointer to the mem _ msg field in the pbuf data structure. Step S40: the module A processes data Z based on the extended pbuf data structure, and mounts the data Z to a payload field of the pbuf data structure; the release function pointer in the mem _ msg field to which the pkt _ msg pointer points is also added to the pbuf release function. Step S50: for data Z forwarded to the module B, the module B reads the mem _ msg field and calls a memory release function pointed by the release function pointer to release the memory occupied by the data Z. The method firstly analyzes the data packets of various TCP/IP protocols, adopts the extension head of the uniform data block to fully reserve the space of the packet head, solves the problem of data modification and filling possibly brought by the data packets passing through each layer and each interface, and avoids subsequent memory copy by the fully reserved space. Meanwhile, aiming at various memory allocation forms in the RTOS system, memory allocation and release fields are designed in the unified data block for recording the release pointer of the memory, so that the principle of who allocates and releases the memory is flexibly and conveniently realized, and the memory is prevented from being leaked.

Further, in step S10, the unified data block format sequentially includes an extension header, an ethernet header, an IP header, a TCP or UDP header, and a payload from front to back. This is a preferred example of a data structure of a unified data block.

Further, in the step S10, the length of the extension header is greater than or equal to the maximum length among the header lengths of the protocols adopted by the different interfaces of the embedded system. This enables the extension headers to be used instead of the headers of the various protocols, thereby unifying the length and format of the data packets of the different interfaces.

Further, in step S10, the protocols adopted by the different interfaces of the embedded system include any one or more of RNDIS protocol, WiFi protocol, and ECM protocol. Several common protocols are listed here as examples.

Further, in step S20, the data structure of the mem _ msg field includes: a release function pointer free for pointing to the memory release function; a data block header pointer mem _ hdr, which is used to point to the first address allocated to the memory, that is, to point to the first address released from the memory; data block length men _ len, which is used to record the length of each uniform data block. This is a preferred example of what the memory allocation and release fields contain.

Further, in step S20, if the data Z is an IP packet, the data Z is written from the IP header position of the uniform data block format. If data Z is an Ethernet packet, data Z is written beginning at the Ethernet header location in the uniform data block format. If the data Z is a data block of an interface of a different protocol, the data Z is written starting from an extended header position of the unified data block format. The start positions of the incoming writes of the data packets of the different interfaces in the unified data block format are given here.

Further, in step S20, the mem _ msg field has a fixed size, and the memory allocation module is responsible for writing. This is a preferred example of the length of the memory allocation and release message field and the write body.

Further, in the step S40, after the modified pbuf release function is executed, the modified pbuf release function is not only used to release the extended pbuf data structure, but also simultaneously executes the memory release function pointed by the release function pointer to release the memory space of the data Z. This is an explanation of the specific functional implementation of modifying the pbuf release function in step S40.

Further, in said step S40, if the pkt _ msg pointer in the extended pbuf data structure is not set with content, then the modified pbuf release function is executed only to release the extended pbuf data structure. If the pkt _ msg variable in the extended pbuf data structure has set contents, then executing the modified pbuf release function releases the memory space allocated by data Z while releasing the extended pbuf data structure. This is a different processing manner given according to whether or not the pkt _ msg pointer is set with content.

The application also provides a device for zero-copy of the memory of the embedded system, which comprises an interface module data block construction unit, an interface module memory allocation unit, an extension unit, a TCP/IP protocol stack processing unit and an interface module memory release unit. The interface module data block construction unit is used for constructing a uniform data block format; the unified data block format comprises a standard header, an extended header and a reserved space; the standard header comprises an ethernet header, an IP header, a TCP or UDP header; the extension header is used for replacing a header of a protocol adopted by a different interface of the embedded system; the reserved space is reserved for a memory allocation and release field, namely a mem _ msg field. The interface module memory allocation unit is used for allocating memory for data Z according to a uniform data block format and configuring a data structure of a mem _ msg field according to memory allocation conditions, wherein the data structure comprises a pointer pointing to a memory release function and a pointer pointing to a memory release address; then writing the mem _ msg field into the reserved space; the interface module memory allocation is also used to write data Z at the corresponding header location in the unified data block format. The extension unit is used to extend the pbuf data structure, adding a pkt _ mac pointer to the ethernet header and a pkt _ msg pointer to the mem _ msg field in the pbuf data structure. The TCP/IP protocol stack processing unit is used for processing data Z based on the extended pbuf data structure and mounting the data Z to a payload field of the pbuf data structure; the release function pointer in the mem _ msg field to which the pkt _ msg pointer points is also added to the pbuf release function. The interface module memory release unit is used for reading a mem _ msg field in a unified data block format of data Z for the data Z forwarded to other modules by the TCP/IP protocol stack processing unit, and calling a memory release function pointed by a release function pointer in the mem _ msg field to release a memory occupied by the data Z. The system optimizes memory allocation and release and data zero copy transfer.

The technical effect that this application obtained is: compared with the traditional memory optimization scheme, a set of more comprehensive optimization scheme is provided by combining the allocation and release of the memory and the transmission of the memory. First, the design scheme is implemented without changing the existing data flow and design framework, and the scheme can be implemented with less code changes for the existing RTOS multi-thread system. Second, RTOS processing systems, particularly adapted to have TCP/IP protocols, can very effectively avoid copying of packets between TCP/IP layers. Thirdly, the risk of memory leakage in the memory allocation and release of the embedded system is solved in an efficient and concise mode, the principle that who allocates and is responsible for memory allocation in the embedded system is met, and the potential memory leakage problem is avoided.

Drawings

FIG. 1 is a block diagram of a typical implementation of an RTOS system for use with embedded network devices.

Fig. 2 is a block diagram of an exemplary implementation of an RTOS system based on the LwIP protocol stack for a wireless router.

Fig. 3 is a simplified schematic diagram of the data format of an IP packet.

Fig. 4 is a simplified schematic diagram of the data format of an IP packet with an ethernet header added.

Fig. 5 is a simplified schematic diagram of the data format of the data blocks of the RNDIS interface.

Fig. 6 is a simplified schematic diagram of the data format of the data blocks of the WiFi interface.

Fig. 7 is a flowchart of a method for zero-copy of an embedded system memory according to the present application.

Fig. 8 is a simplified schematic diagram of a data format of a unified data block proposed in the present application.

Fig. 9 is a schematic diagram of the process of data Z flowing between different modules in step S50.

Fig. 10 is a schematic structural diagram of an apparatus for zero-copy of an embedded system memory according to the present application.

The reference numbers in the figures illustrate: 10 is an interface module data block construction unit; 20 is an interface module memory allocation unit; 30 is an extension unit; 40 is TCP/IP protocol stack processing unit; and 50 is an interface module memory release unit.

Detailed Description

Referring to fig. 1, a block diagram of an exemplary implementation of an RTOS system for use with an embedded network device is shown. Embedded Network devices typically have multiple LAN (Local Area Network) interfaces and at least one WAN (Wide Area Network) interface. The LAN interface is abbreviated as LAN port, and the WAN interface is abbreviated as WAN port. The LAN ports share single or multiple WAN interfaces to access the Internet network through the message processing main thread in the RTOS system. Each LAN port may be used to connect to an access device. The WAN port may be used to connect to a network egress device. As shown in fig. 1, there may be a plurality of message processing threads and a plurality of interfaces in the RTOS-based system, and each interface may correspond to a different access protocol.

The wireless router is a typical embedded system, and is generally implemented by using an RTOS system in cooperation with a TCP/IP protocol stack dedicated to the embedded system. lwIP (light IP) is an open source TCP/IP protocol stack and is widely used in embedded system development. Referring to fig. 2, a block diagram of an exemplary implementation of an RTOS system based on a LwIP protocol stack of a wireless router, for example, ThreadX widely used in the embedded field. The wireless router realizes mobile communication data access WAN ports of 3G, 4G, 5G and the like by a single-chip scheme; RNDIS (Remote Network driver interface Specification)/ECM (Ethernet Control Model) interface and WiFi interface are used as LAN ports for intranet access, allowing access devices (such as PC hosts and the like) to share mobile communication data traffic to access the internet. This is a specific implementation of a general wireless router device, which will be described below as an example, but the principles of the present application may be extended to other embedded systems involving memory allocation management, and are not limited to wireless router devices.

As shown in fig. 2, the processing procedure of the data in the embedded system, which takes a wireless router as an example, is divided into two paths, namely an uplink path and a downlink path. For the upstream channel, the data flow direction is: PC host- > LAN interface (WiFi interface, or RNDIS/ECM interface) - > LwIP message processing main thread- > WAN interface (3G/4G interface). For the downlink channel, the data flow direction is: WAN interface (3G/4G interface) > LwIP message processing main thread- > LAN interface (WiFi interface, or RNDIS/ECM interface) > PC host. The data processed by uplink and downlink are mainly IP data packets, but different data interfaces are used, for example, an IP data packet is directly received and transmitted by a WAN interface, an IP data packet with a WiFi protocol header and an ethernet header is received and transmitted by a WiFi interface (LAN interface), and an IP data packet with an RNDIS protocol header and an ethernet header is received and transmitted by an RNDIS interface. In addition, each interface receives and transmits data in a memory use mode, for example, when a WAN port processes downlink data, the 3G/4G module allocates a memory in a mode of itself, and then sends the memory to the LwIP message processing main thread, and the processing mode of each LAN port on memory allocation is similar to this.

From the design angle of module decoupling, when carrying out data transfer between module and the module, it is most reasonable to adopt the mode of memory copy, does not have data coupling between module and the module like this, does not have the problem that who distributes who releases yet, and new head is added according to the demand of each layer to each layer yet, and the biggest defect of this kind of design is exactly that bring huge memory copy overhead and loss of performance. Therefore, how to solve the problem of minimum overhead transmission of data among modules and avoid memory leakage becomes a key of design.

In the wireless router apparatus shown in fig. 2, the data blocks transmitted and received by the respective data interfaces have different forms.

Referring to fig. 3, the format of the IP data packet sequentially includes an IP header, a TCP or UDP header, and a payload (payload). For a 3G/4G interface with a WAN port, the data blocks are typically in an IP packet format.

Referring to fig. 4, the format of the IP packet (i.e., ethernet packet) with the ethernet header added thereto includes an ethernet header, an IP header, a TCP or UDP header, a payload, and the like.

Referring to fig. 5, if the LAN interface is the RNDIS interface, the data block format to be transmitted and received sequentially includes RNDIS protocol header, ethernet header, IP header, TCP or UDP header, payload, and the like.

Referring to fig. 6, if the LAN interface is a WiFi interface, the data block format to be transmitted and received sequentially includes a WiFi protocol header, an ethernet header, an IP header, a TCP or UDP header, a payload, and the like.

As can be seen from fig. 3 to 6, the data blocks transmitted and received by the respective interfaces have different forms, and have a common part and different parts. But it is clear that different protocol header lengths are predictable.

Referring to fig. 7, the method for zero-copy of the memory of the embedded system according to the present application includes the following steps.

Step S10: a unified data block format is employed, including a standard header, an extended header, and a reserved space. The standard header includes an ethernet header, an IP header, a TCP or UDP header, in that order from front to back. The extension header precedes the standard header and is used to replace a protocol header used by a different interface of the embedded system, such as a RNDIS protocol header, a WiFi protocol header, an ECM interface protocol header, or other protocol header, and the extension header is designed to have a length greater than or equal to a maximum length of one or more of the required protocol headers. The reserved space is used to reserve memory allocation and release fields before extending the header. The memory allocation and release field is named as mem _ msg, and self-adaptive memory release requirements are realized.

Referring to fig. 8, the unified data block format proposed in the present application sequentially includes a reserved space, an extension header, an ethernet header, an IP header, a TCP or UDP header, a payload, and the like. The ethernet header, IP header, TCP or UDP header collectively referred to as the standard header.

Step S20: for a data packet (hereinafter referred to as data Z) of any interface, the module a allocates a memory according to a uniform data block format, and configures a data structure of a mem _ msg field according to a memory allocation condition, mainly setting a memory release function and a memory release address. Module a then writes the mem _ msg field into the reserved space while writing the data of data Z at the corresponding header location of the unified data block format. For example, for the ethernet packet shown in fig. 4, the ethernet data is written starting from the ethernet header position of the unified data block format. As another example for the IP packet shown in fig. 3, the IP data is written starting from the IP header position of the unified data block format. As for the data blocks of the different interfaces shown in fig. 5 or fig. 6, the data blocks are written starting from the extended header position of the unified data block format.

As an example, the data structure of the mem _ msg field is designed as follows, where/'to'/content is the comment specification.

The mem _ msg field is fixed in size, so that the format of the unified data block can be conveniently expanded, wherein the most critical parameter is a release function pointer free which is used for pointing to a memory release function, and the memory allocation module is responsible for writing. The data block header pointer mem _ hdr is used to point to the memory allocated first address, i.e. to point to the memory freed first address. The data block length men _ len records the length of each uniform data block.

Step S30: the module a extends the data structure of pbuf, and adds a pointer to the ethernet header and a pointer to the memory allocation and release field mem _ msg, so as to speed up the processing of the ethernet module and the memory release module.

The pbuf data structure is the data structure in the LwIP protocol stack used to organize TCP/IP packets. A complete TCP/IP packet may be implemented by a pbuf data structure, or by a pbuf chain (pbuf chain) consisting of pbuf data structures. For other embedded TCP/IP protocol stacks, there is a similar data structure to organize TCP/IP packets. The pbuf data structure of the LwIP protocol stack is taken as an example for explanation, and the same principle is also applicable to other TCP/IP protocol stacks.

The extended pbuf data structure proposed in this application is briefly described as follows, where/'to'/between are the annotation descriptions.

In the pbuf data structure, the pkt _ mac variable is newly added in the present application, and is a pointer to the ethernet header position. The pkt _ msg variable is also newly added to this application and is a pointer to the memory allocation and release field mem _ msg location.

Step S40: and the module A processes the data Z adopting the uniform data block format based on the extended pbuf data structure, and mounts the data Z adopting the uniform data block format to the payload field of the pbuf data structure. Module a also adds to the pbuf release function the release function pointer free in the memory allocation and release field mem _ msg pointed to by the pkt _ msg variable. The conventional pbuf release function, after execution, is only used to release the pbuf data structure. After the modified pbuf release function is executed, the modified pbuf release function is not only used for releasing the extended pbuf data structure, but also used for simultaneously executing the memory release function pointed by the release function pointer free to release the memory space of the data Z. Thus, the memory release operation involved in the TCP/IP protocol processing of the data Z is seamlessly embedded into the release operation of the pbuf data structure.

Specifically, if the pkt _ msg variable in the extended pbuf data structure is not set, then the pbuf release function is performed only to release the extended pbuf data structure. If the pkt _ msg variable in the extended pbuf data structure is set, then executing the pbuf release function releases the memory allocated by data Z while releasing the extended pbuf data structure.

Step S50: for the data Z which is forwarded to the module B and adopts the uniform data block format, the module B reads the memory allocation and release field mem _ msg of the uniform data block format, and calls the memory release function pointed by the release function pointer free therein to release the memory occupied by the data Z.

The steps S10 to S40 are all data processing performed inside the TCP/IP protocol stack, for example, processing by using the LwIP protocol stack. After step S40 is completed, there are two possible cases of data Z. The situation is that the data Z has already been processed inside the TCP/IP protocol stack. Case two is that data Z leaves the TCP/IP protocol stack to be processed by other modules. Step S50 describes the second case, in which the module B may still call the memory release function to release the memory space of the data Z based on the pointer to the memory release function in the unified data block format. FIG. 9 schematically depicts the process of transferring the data Z shown in steps S20 and S50 between different modules.

Referring to fig. 10, the embedded system memory zero-copy apparatus provided in the present application includes an interface module data constructing unit 10, an interface module memory allocating unit 20, an extending unit 30, a TCP/IP protocol stack processing unit 40, and an interface module memory releasing unit 50.

The interface module data block construction unit 10 is used to construct a unified data block format. The unified data block format includes a standard header, an extended header, and a reserved space. The standard header includes an ethernet header, an IP header, a TCP or UDP header. The extension header is used to replace the header of a protocol employed by a different interface of the embedded system. The reserved space is reserved for a memory allocation and release field, namely a mem _ msg field.

The interface module memory allocation unit 20 is configured to allocate a memory for the data Z according to a uniform data block format, and configure a data structure of a mem _ msg field according to a memory allocation condition, where the data structure includes a pointer pointing to a memory release function and a pointer pointing to a memory release address; the mem _ msg field is then written to the reserved space. The interface module memory allocation 20 is also used to write data Z at the corresponding header location in the unified data block format.

The extension unit 30 is used to extend the pbuf data structure in which a pkt _ mac pointer to the ethernet header and a pkt _ msg pointer to the mem _ msg field are added.

The TCP/IP stack processing unit 40 is configured to process the data Z based on the extended pbuf data structure, and mount the data Z to a payload field of the pbuf data structure; the release function pointer in the mem _ msg field to which the pkt _ msg pointer points is also added to the pbuf release function.

The interface module memory releasing unit 50 is configured to, for the data Z forwarded to another module by the TCP/IP protocol stack processing unit 40, read a mem _ msg field in a unified data block format of the data Z, and call a memory release function pointed by a release function pointer therein to release a memory occupied by the data Z.

Compared with the existing memory allocation and management method of the embedded system, the method has the following beneficial effects.

Firstly, each data interface of the embedded system pre-allocates data blocks according to a uniform data format, and meanwhile, a pbuf data structure in an LwIP protocol stack is combined to record a pointer pointing to a payload of an IP data packet, based on a data position of an IP header, each layer needs to process data of which header only by performing relative offset on the header, and there is no need to reallocate a memory to add the header, and there is no need to worry about insufficient memory space or memory address errors. Therefore, the problem of data copying in the memory transfer process is solved in a unified data block mode.

Secondly, the pointer of the memory release function is recorded in the newly added mem _ msg field, so that other modules can call the memory release function conveniently according to the pointer, and the memory is released in a self-adaptive manner. Taking fig. 9 as an example, when the module B finally releases the data block, the memory release function set by the module a is called to release the memory, and the module B does not need to care about the specific allocation form of the memory, regardless of RAM memory allocation, ROM memory allocation, or memory pool allocation, or other forms of memory allocation, as long as the module a sets the corresponding memory release function and fills in the correct mem _ msg field, the module B can correctly release the memory. The processing mode really realizes the principle of who distributes and releases in system design, and avoids the potential memory leakage problem.

Thirdly, the data block is initially distributed from the module A, processed by a plurality of modules and finally released from the module B, zero-copy data flow is achieved, only the data block pointer needs to be brought to the next processing module, and the processing performance of the whole system is greatly improved.

The above are merely preferred embodiments of the present application and are not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application.