Master core module, slave core module and TCP communication method of heterogeneous multi-core system

Abstract

The invention relates to a master core module, a slave core module and a TCP communication method of a heterogeneous multi-core system, and belongs to the technical field of heterogeneous multi-cores. A main core proxy type TCP communication mechanism is adopted, a TCP / IP protocol stack is only operated in the main core module, memory and CPU resource waste caused by repeated loading of the protocol stack by each slave core is avoided, the slave core module interacts with the main core through a lightweight message queue, a physical network port is not occupied, hardware port resource overhead is greatly reduced, the main core executes TCP operation in a centralized manner, and the communication efficiency is improved. Multi-core redundancy processing is avoided, inter-core low-delay and high-throughput instruction transmission is achieved, and the real-time performance of system communication is remarkably improved. Therefore, the problems that an existing AMP heterogeneous multi-core system is high in network communication resource occupation, a protocol stack is repeatedly achieved, and the system is difficult to maintain in a unified mode are solved. Compared with a traditional scheme, the method has remarkable advantages in the aspects of resource utilization and communication efficiency.

Description

Technical Field

[0001] This invention relates to a master core module, a slave core module, and a TCP communication method for a heterogeneous multi-core system, belonging to the field of heterogeneous multi-core technology. Background Technology

[0002] In heterogeneous multi-core systems, existing technologies mainly employ the following two methods to achieve TCP communication between the master / slave cores and external networks: The first approach involves each core directly running the TCP / IP protocol stack to implement TCP communication. In this architecture, each core independently loads and runs the complete TCP / IP protocol stack, thus enabling direct communication with external devices. While simple to implement and able to directly utilize the mature TCP protocol, this approach has significant drawbacks: each core needs to allocate substantial memory and CPU resources for its independent protocol stack, multiplying resource consumption; multiple cores maintain separate socket connections, resulting in fragmented connection states and a lack of unified management, making system maintenance difficult; furthermore, this solution typically requires configuring a separate physical network interface for each core, or introducing a complex multi-core scheduling mechanism on the same network interface, increasing both hardware costs and implementation complexity. As the number of cores increases, the repetitive execution of the protocol stack and the difficulty in expanding physical interfaces lead to extremely poor system scalability.

[0003] The second approach uses virtual Ethernet combined with NFS (Network File System) for communication. In this scheme, the master core runs the TCP / IP protocol stack and provides NFS file services, while the slave cores mount the master core's NFS through virtual network interface cards (NICs) to achieve data exchange. Although it reuses the standard protocol stack and file system interface, it also has drawbacks: the slave cores still need to run virtual NIC drivers and parts of the network protocol stack, increasing system overhead; the virtual Ethernet + NFS file access mode requires processing through multiple levels of protocols, including the virtual NIC layer, TCP layer, and NFS layer, resulting in high communication latency, which cannot meet the rapid response requirements of real-time control systems; at the same time, the virtual network interface configuration is complex, the synchronization mechanism is cumbersome, and each additional slave core requires additional configuration and resources, limiting scalability.

[0004] In summary, both of the existing mainstream solutions suffer from high resource consumption, complex implementation and maintenance, insufficient real-time performance, and poor scalability, making them particularly difficult to meet practical needs in scenarios such as industrial control where high reliability, low latency, and low cost are critical. Summary of the Invention

[0005] The purpose of this invention is to provide a master core module, slave core module, and TCP communication method for a heterogeneous multi-core system, so as to solve the problems of high resource overhead and insufficient real-time performance in current heterogeneous multi-core systems when communicating with external systems.

[0006] To address the aforementioned technical problems, this invention provides a TCP communication method for heterogeneous multi-core systems, the method comprising: Select one core module from the heterogeneous multi-core system as the master core module and the others as slave core modules. Run the TCP / IP protocol stack in the master core module and use the master core module as the external communication interface to establish communication connections with the outside world. The master core module proxies and completes all network-related services. The slave module establishes a connection with the master module through an inter-core message queue to enable data transmission and reception and status feedback.

[0007] Furthermore, the main core module establishes a communication connection with the outside world using the running TCP / IP protocol stack based on the TCP communication request initiated from the outside.

[0008] Furthermore, the message queue in which the slave module establishes a connection with the master module through the inter-core message queue includes a first message queue created by the master module for each slave module and a second message queue created by each slave module. The first message queue is used to store instructions forwarded by the master module to the slave module; the second message queue is used to store response messages of the operation results executed by the slave module according to the received instructions.

[0009] Furthermore, when the main core module detects an externally sent instruction, it parses the instruction. If the instruction can be directly completed by the main core module, the main core module performs the corresponding operation according to the instruction; if the instruction needs to be processed by the slave core module, the main core module sends the instruction to the corresponding slave core module through the first message queue.

[0010] Furthermore, the slave core module is used to execute corresponding operations according to the instructions in the corresponding first message queue, and encapsulate the operation results into a response message and send it to the main core module through the corresponding second message queue.

[0011] Furthermore, the main core module is also used to feed back the operation results executed by the main core module and / or the response messages obtained from the second message queue to the outside.

[0012] The present invention also provides a main core module for a heterogeneous multi-core system. The main core module runs a TCP / IP protocol stack and serves as the external communication interface for the heterogeneous multi-core system. It is used to establish communication connections with external systems and to establish connections with slave core modules through inter-core message queues to achieve data transmission and reception and status feedback.

[0013] Furthermore, the main core module is used to create a first message queue for each slave core module, and when it hears an instruction sent from the outside, it parses the instruction. If the instruction can be completed directly by the main core module, the main core module performs the corresponding operation according to the instruction; if the instruction needs to be processed by the slave core module, the main core module sends the instruction to the corresponding slave core module through the first message queue.

[0014] The present invention also provides a slave core module for a heterogeneous multi-core system. The slave core module is used to establish a connection with the master core module through an inter-core message queue, receive instructions forwarded by the master core module through the inter-core message queue, perform corresponding operations according to the instructions, and feed back the operation results to the master core module through the inter-core message queue, so as to realize data transmission and reception and status feedback.

[0015] Furthermore, a second message queue is created from the kernel module to receive instructions forwarded by the main kernel module through the first message queue created by the main kernel module, perform corresponding operations on the received instructions, and encapsulate the operation results into a response message and send it to the main kernel module through the corresponding second message queue.

[0016] The beneficial effects of this invention are as follows: This invention adopts a master-core proxy TCP communication mechanism, running the TCP / IP protocol stack only on the master core module. This avoids the waste of memory and CPU resources caused by repeated loading of the protocol stack on each slave core. The slave core modules interact with the master core through a lightweight message queue, without occupying physical network ports, significantly reducing hardware port resource overhead. The master core centrally executes TCP operations, avoiding redundant processing across multiple cores, achieving low-latency, high-throughput instruction transmission between cores, and significantly improving the real-time performance of system communication. Therefore, this invention solves the problems of high network communication resource consumption, redundant protocol stack implementation, and difficulty in unified system maintenance in existing AMP heterogeneous multi-core systems. Compared with traditional solutions, this invention has significant advantages in resource utilization and communication efficiency. Attached Figure Description

[0017] Figure 1 This is a block diagram of the master-slave core communication proxy structure of the heterogeneous multi-core system of the present invention; Figure 2 This is a flowchart of the main core module processing of the heterogeneous multi-core system of the present invention; Figure 3 This is a flowchart of the slave core module processing of the heterogeneous multi-core system of the present invention; Figure 4 This is a timing diagram of the communication between the master and slave core modules of the heterogeneous multi-core system of this invention. Detailed Implementation

[0018] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0019] This invention employs a master-core proxy TCP communication mechanism, which runs the TCP / IP protocol stack only on the master core module. This avoids the waste of memory and CPU resources caused by the repeated loading of the protocol stack by each slave core. The slave core modules interact with the master core through a lightweight message queue, without occupying physical network ports, thus significantly reducing hardware port resource overhead. The master core centrally executes TCP operations, avoiding redundant processing by multiple cores, and achieving low-latency, high-throughput instruction transmission between cores, significantly improving the real-time performance of system communication.

[0020] Implementation of TCP communication methods for heterogeneous multi-core systems like Figure 1 As shown, the heterogeneous multi-core system of the present invention mainly consists of a master core module (hereinafter referred to as the master core) and a slave core module (hereinafter referred to as the slave core). The master core module runs a complete TCP / IP protocol stack and proxy thread, and is responsible for the establishment, maintenance, data transmission and reception and closing of all TCP connections. At the same time, it serves as the only external network interface and maintains a long connection with the graphical tool. The slave core module only undertakes local business logic processing and interacts with the master core through inter-core message queues without needing to care about the details of TCP protocol implementation. Inter-core communication channel: based on inter-core shared memory, a lightweight message queue (MSGQ_MASTER[i] / MSGQ_CORE) is used to establish an independent channel for each slave core to achieve lock-free and high-throughput instruction interaction. The message queues used by the slave core module to establish a connection with the master core module through the inter-core message queue include a first message queue (MSGQ_MASTER[i]) created by the master core module for each slave core module and a second message queue (MSGQ_CORE) created by each slave core module. The first message queue is used to store instructions forwarded by the master core module to the slave core module; the second message queue is used to store response messages of the operation results executed by the slave core module according to the received instructions. In other words, the principle of message queue usage is: both the master and slave cores write to their own queues and read from the other's queues. The functions of each module are described in detail below.

[0021] 1. Main Core Module In this embodiment, the main core module is the core communication control unit of the multi-core heterogeneous system. It runs a complete TCP / IP protocol stack and manages all TCP link operations uniformly through a proxy thread (xchgMsgTask). This thread is closely integrated with the kernel network stack and undertakes three main functions: instruction parsing from the kernel module, TCP operation execution, and result feedback. The specific workflow is as follows: Figure 2 As shown, it includes: During the initialization phase, the main core module loads the TCP / IP protocol stack, establishes a communication connection with the external network, and creates an independent message queue MSGQ_MASTER[i] (i.e., the first message queue) for each slave core module, where i represents the i-th slave core module. In this implementation, i = 1, 2, ..., n, and n is the number of slave core modules to ensure that multiple cores do not interfere with each other. The [xchgMsgTask] agent thread is started to continuously listen to the MSGQ_CORE[i] queue and process instructions.

[0022] During runtime, the master core proxy handles all TCP operations (connect, send, recv, close) with external clients. It continuously monitors the input to the MSGQ_CORE[i] queue via a proxy thread. When a slave core sends a command (a response message from the slave core to the master core's message) to the MSGQ_CORE[i] queue, the proxy thread parses the command type, calls the corresponding socket API interface for processing based on the command type, and performs error handling or timeout control when necessary. Message types include sending data, receiving data, establishing a connection, and status querying. The corresponding socket API interfaces include send(), recv(), and connect(). For example, if the parsed command type is establishing a connection, connect() is called to perform the connection establishment operation. Simultaneously, the master core module also packages the operation results into response messages and returns them to the slave core module through the corresponding MSGQ_MASTER[i] queue. That is, the master core receives the slave core's response message, performs the corresponding TCP operation, and can also send the operation results back to the slave core.

[0023] 2. From the kernel module The slave core module only handles local business logic and data processing, without directly participating in the implementation of the TCP / IP protocol stack. Instead, it interacts with the master core via an inter-core message queue and communicates with external systems through connections established between the master core and external systems. This design allows the slave core module to collaborate with the master core module in a lightweight, protocol-stack-free manner without consuming network protocol stack resources or relying on physical network interfaces, achieving a low-latency, high-reliability, and scalable inter-core communication mechanism. In this implementation, there are multiple slave core modules, each with the same workflow, such as... Figure 3 As shown, the specific workflow includes: Initialization phase: The slave core module initializes and creates a message queue MSGQ_CORE (also called the second message queue) to communicate with the master core module. Each slave core module creates an MSGQ_CORE message queue, and then the slave core enters a blocked waiting state. In this state, the slave core module waits for the master core module to send command messages through the corresponding MSGQ_MASTER[i] (the first message queue of the i-th slave core). When the slave core module receives the command message sent by the master core module, it parses the command message and extracts information such as instruction type (command), data pointer, and timeout parameters from the message.

[0024] Task execution phase: The kernel module executes local logic or accesses local resources according to the parsed instruction type and generates processing results; the processing results are encapsulated into standard response messages and sent back to the main kernel through the MSGQ_CORE message queue for further processing by the main kernel and external forwarding.

[0025] Re-entering the waiting state: After completing a task, the kernel returns to the blocked waiting state, ready to receive the next master kernel command.

[0026] 3. Master-slave nuclear communication Based on the analysis of the functions of the master core and slave core modules, the master-slave core communication process is described below. This master-slave core communication process is the key mechanism for achieving external TCP communication and internal multi-core collaborative work in this invention. The multi-core system of this invention adopts a centralized proxy architecture, with the master core serving as the sole external communication interface. It establishes and maintains TCP connections with external graphical tools by running the TCP / IP protocol stack. All network-related services are handled by the master core proxy, while slave cores only need to interact with the master core through inter-core message queues to achieve data transmission and reception and status feedback. This centralized proxy communication process realizes a collaborative mechanism where the master core centrally manages TCP / IP network access and slave cores independently execute local operations. This ensures both system scalability and unified scheduling and management of network resources in a multi-core environment. The specific implementation process is as follows: Figure 4 As shown below, the master-slave core communication process will be explained in detail in conjunction with this process.

[0027] 1) External request access: When the main core module receives an external communication request, i.e. a TCP request, it establishes a connection through its own running TCP / IP protocol stack and maintains the connection state information uniformly. All subsequent data exchanges are carried out through this connection. In this embodiment, the TCP communication request is initiated through a graphical tool.

[0028] 2) Main core module parsing instructions: After receiving external instructions through the established connection, the main core module enters the parsing process. Based on the instruction type and parameters, it determines the processing method of the task. In this embodiment, there are two processing methods: local processing and processing from the kernel. The main core module performs two types of processing based on the parsing result of the external instructions. When it is parsed as local processing, it enters branch 1; when it is parsed as processing from the kernel, it enters branch 2.

[0029] Branch 1: Local processing: The main core executes corresponding operations based on the specific type of the instruction. These types include sending data, receiving data, establishing a connection, and status querying. The main core immediately executes the corresponding logic based on the type and encapsulates the result into response data, which is then returned to the external system via the TCP / IP protocol stack—the graphical interface in this implementation. For example, if the parsed instruction type is "send data," then `send()` is called to perform the data sending operation, and the execution result is fed back to the graphical interface, allowing the user to understand the instruction's execution status from the graphical interface.

[0030] Branch 2: Processing from the kernel: If a task involves specific resources of a slave core or needs to be executed by a slave core (e.g., specific processing involving slave core local resources, device interfaces, or data buffers), the master core encapsulates the instructions, data pointers, timeout parameters, etc., into a message and sends it to the target slave core (the i-th core) through the maintained MSGQ_MASTER[i] message queue. For example, when a task needs to be processed by slave core 1, the master core sends the encapsulated message to slave core 1 through the MSGQ_MASTER[1] message queue. A task may also involve multiple slave cores. In this case, the master core sends the encapsulated message to the involved slave cores through the corresponding MSGQ_MASTER[i] message queues. For example, if slave core 1, slave core 2, and slave core n are involved at the same time, the master core sends the encapsulated message to slave core 1, slave core 2, and slave core n through the MSGQ_MASTER[1] message queue, the MSGQ_MASTER[2] message queue, and the MSGQ_MASTER[n] message queue, respectively.

[0031] 3) Execution and return from the kernel: When the slave core starts up, it creates an MSGQ_CORE queue to communicate with the master core and is in a listening state. When it receives a message forwarded by the master core, the slave core parses the command content, executes local logic or device-related operations, and encapsulates the processing result into an acknowledgment message, which is then returned to the master core through MSGQ_CORE. For example, when slave core 1 receives a message forwarded by the master core through the MSGQ_MASTER[1] message queue, the slave core parses the command content in the message, executes the corresponding local logic device-related operations according to the parsed command content, and encapsulates the results of the executed operations into an acknowledgment message, which is then sent to the master core through the MSGQ_CORE[1] message queue.

[0032] 4) The main core returns an external response: The master core receives and parses the response message from the slave core from the MSGQ_CORE message queue, generates a final response, and sends it to an external graphical tool through the TCP / IP protocol stack. For example, the master core receives and parses the response message from slave core 1 from the MSGQ_CORE[1] message queue, generates a final response based on the response message, and sends the generated final response to an external graphical tool through a connection established by the TCP / IP protocol stack so as to understand the execution result of the slave core in a timely manner.

[0033] 5) Loop processing: After the task is completed, both the master core and the slave core return to the waiting state, ready to process the next instruction, thus achieving continuous and efficient communication and interaction.

[0034] Implementation of the main core module in a heterogeneous multi-core system The main core module is the core communication control unit of a multi-core heterogeneous system. It runs a complete TCP / IP protocol stack and manages all TCP link operations through a proxy thread (xchgMsgTask). This thread is tightly integrated with the kernel network stack and undertakes three main functions: instruction parsing from the kernel module, TCP operation execution, and result feedback. The specific workflow is as follows: Figure 2 As shown, it includes: During the initialization phase, the main core module loads the TCP / IP protocol stack, establishes a communication connection with the external network, and creates an independent message queue MSGQ_MASTER[i] (i.e., the first message queue) for each slave core module, where i represents the i-th slave core module. In this implementation, i = 1, 2, ..., n, and n is the number of slave core modules to ensure that multiple cores do not interfere with each other. The [xchgMsgTask] agent thread is started to continuously listen to the MSGQ_CORE[i] queue and process instructions.

[0035] During runtime, the master core proxy handles all TCP operations (connect, send, recv, close) with external clients. It continuously monitors the input to the MSGQ_CORE[i] queue via a proxy thread. When a slave core sends a command (a response message from the slave core to the master core's message) to the MSGQ_CORE[i] queue, the proxy thread parses the command type, calls the corresponding socket API interface for processing based on the command type, and performs error handling or timeout control when necessary. Message types include sending data, receiving data, establishing a connection, and status querying. The corresponding socket API interfaces include send(), recv(), and connect(). For example, if the parsed command type is establishing a connection, connect() is called to perform the connection establishment operation. Simultaneously, the master core module also packages the operation results into response messages and returns them to the slave core module through the corresponding MSGQ_MASTER[i] queue. That is, the master core receives the slave core's response message, performs the corresponding TCP operation, and can also send the operation results back to the slave core.

[0036] Slave kernel module implementation of heterogeneous multi-core systems The slave core module only handles local business logic and data processing, without directly participating in the implementation of the TCP / IP protocol stack. Instead, it interacts with the master core via an inter-core message queue and communicates with external systems through connections established between the master core and external systems. This design allows the slave core module to collaborate with the master core module in a lightweight, protocol-stack-free manner without consuming network protocol stack resources or relying on physical network interfaces, achieving a low-latency, high-reliability, and scalable inter-core communication mechanism. In this implementation, there are multiple slave core modules, each with the same workflow, such as... Figure 3 As shown, the specific workflow includes: Initialization phase: The slave core module initializes and creates a message queue MSGQ_CORE (also called the second message queue) to communicate with the master core module. Each slave core module creates an MSGQ_CORE message queue, and then the slave core enters a blocked waiting state. In this state, the slave core module waits for the master core module to send command messages through the corresponding MSGQ_MASTER[i] (the first message queue of the i-th slave core). When the slave core module receives the command message sent by the master core module, it parses the command message and extracts information such as instruction type (command), data pointer, and timeout parameters from the message.

[0037] Task execution phase: The kernel module executes local logic or accesses local resources according to the parsed instruction type and generates processing results; the processing results are encapsulated into standard response messages and sent back to the main kernel through the MSGQ_CORE message queue for further processing by the main kernel and external forwarding.

[0038] Re-entering the waiting state: After completing a task, the kernel returns to the blocked waiting state, ready to receive the next master kernel command.

[0039] In summary, this invention, through its innovative use of a master-core proxy TCP communication mechanism, solves the problems of high network communication resource consumption, redundant protocol stack implementation, and difficulty in unified system maintenance in existing AMP heterogeneous multi-core systems. Compared with traditional solutions, this invention has significant advantages in resource utilization, communication efficiency, system architecture, and scalability.

[0040] Efficient resource utilization: The complete TCP / IP protocol stack runs only on the main core, avoiding the waste of memory and CPU resources caused by repeatedly loading the protocol stack on each slave core; the slave cores interact with the main core through lightweight message queues, without occupying physical network ports, significantly reducing hardware port resource overhead. This solution can be linearly scaled in AMP heterogeneous platforms with 4 cores, 8 cores, and more, without requiring additional resource configuration.

[0041] Highly efficient and real-time communication: TCP operations are centrally executed on the main core, avoiding redundant processing across multiple cores. A standardized message format and a bidirectional lock-free message queue mechanism are employed to achieve low-latency, high-throughput instruction transmission between cores, significantly improving the real-time performance of system communication.

[0042] Simple and maintainable architecture: Through standardized message interfaces, business logic is completely decoupled from the network protocol stack. The kernel does not need to care about TCP details and can only focus on local business processing. The centralized proxy mechanism simplifies the system architecture design, reduces the difficulty of development and debugging, and facilitates later expansion and maintenance.

[0043] High reliability and scalability: Each slave core uses an independent message channel, supporting concurrent instruction processing across multiple slave cores; the master core agent thread is uniformly scheduled to ensure stable operation under high load conditions and can be flexibly expanded to more cores and more complex application scenarios.

[0044] In summary, this invention realizes a low-overhead, high-efficiency, scalable and easy-to-maintain TCP communication proxy architecture in heterogeneous multi-core systems, which can be widely used in industrial control, real-time computing and multi-core network communication, and has significant technical value and application prospects.

Claims

1. A TCP communication method of a heterogeneous multi-core system, characterized by, The method comprises: selecting one from a heterogeneous multi-core system as a master core module and the others as slave core modules, running a TCP / IP protocol stack in the master core module, taking the master core module as an external communication interface to establish a communication connection with the outside, and completing all network-related services by the master core module proxy; the slave core modules establish a connection with the master core module through an inter-core message queue to realize data transmission and state feedback.

2. The TCP communication method of a heterogeneous multi-core system according to claim 1, wherein, The master core module establishes a communication connection with the outside according to an externally initiated TCP communication request by using the running TCP / IP protocol stack.

3. The method of claim 1, wherein the method further comprises: The message queue in the connection established by the slave core modules with the master core module through the inter-core message queue comprises a first message queue created by the master core module for each slave core module and a second message queue created by each slave core module, the first message queue is used for storing instructions forwarded by the master core module to the slave core module, and the second message queue is used for storing response messages of operation results executed by the slave core module according to the received instructions.

4. The TCP communication method of a heterogeneous multi-core system according to claim 3, wherein, When the master core module listens to an instruction sent by the outside, the master core module analyzes the instruction, executes corresponding operations according to the instruction if the instruction can be directly completed by the master core module, and sends the instruction to the corresponding slave core module through the first message queue if the instruction needs to be processed by the slave core module.

5. The method of claim 4, wherein, The slave core module is used for executing corresponding operations according to the instructions in the corresponding first message queue and encapsulating operation results as response messages to send to the master core module through the corresponding second message queue.

6. The method of claim 3, wherein the TCP communication method of the heterogeneous multi-core system is characterized by, The master core module is also used for feeding back operation results executed by the master core module and / or response messages obtained from the second message queue to the outside.

7. A host core module of a heterogeneous multi-core system, the host core module comprising: The master core module runs a TCP / IP protocol stack, and is an external communication interface of the heterogeneous multi-core system, is used for establishing a communication connection with the outside, is used for establishing a connection with the slave core modules through an inter-core message queue to realize data transmission and state feedback.

8. The host core module of a heterogeneous multicore system according to claim 7, wherein, The master core module is used for creating a first message queue for each slave core module, analyzing an instruction sent by the outside when the master core module listens to the instruction, executing corresponding operations according to the instruction if the instruction can be directly completed by the master core module, and sending the instruction to the corresponding slave core module through the first message queue if the instruction needs to be processed by the slave core module.

9. A slave core module of a heterogeneous multi-core system, characterized by comprising: The slave core module is used for establishing a connection with the master core module through an inter-core message queue, receiving instructions forwarded by the master core module through the inter-core message queue, executing corresponding operations according to the instructions, and feeding back operation results to the master core module through the inter-core message queue to realize data transmission and state feedback.

10. The slave core module of a heterogeneous multi-core system according to claim 9, wherein, The slave core module creates a second message queue, is used for receiving instructions forwarded by the master core module through the first message queue created by the master core module, executing corresponding operations on the received instructions, and encapsulating operation results as response messages to send to the master core module through the corresponding second message queue.

Images