Method for data interaction between linux platform application layer and mcdma module based on netlink

Abstract

This invention discloses a method for data interaction between the application layer and MCDMA module on a Linux platform based on Netlink. The method involves establishing a mapping relationship between DMA channels and Netlink port numbers / PIDs during the creation of the kernel MCDMA driver process. User-layer applications can interact with the corresponding DMA channels using the Netlink port / PID and Netlink data transmission methods. User-layer applications can also interact with kernel threads using standard socket interfaces for DMA data exchange. This method simplifies the implementation of DMA data transmission and reception requirements at the application layer. Furthermore, this method utilizes Netlink's asynchronous buffering feature; data sent is temporarily stored in the receiver's socket queue, eliminating the need to wait for the receiver to complete data reception.

Description

Technical Field

[0001] This invention relates to the field of wired communication equipment and discloses a method for data interaction between the application layer of a Linux platform and an MCDMA module based on Netlink. Background Technology

[0002] Typically, when user-level applications need to interact with the kernel, they use three methods: system calls, ioctl, and the / proc file system. These methods are all synchronous, and data transmission can only be initiated by the application layer.

[0003] Currently, the aforementioned technologies have many technical problems and require further research and innovation. Summary of the Invention

[0004] Purpose of the invention: To provide a method for data interaction between the application layer and MCDMA module of a Linux platform based on Netlink, so as to solve the above-mentioned problems existing in the prior art.

[0005] Technical solution: A method for data interaction between the application layer and MCDMA module on a Linux platform based on Netlink, comprising the following steps:

[0006] S1. Start the device, load the kernel MCDMA driver module, and initialize all DMA channels in the driver module;

[0007] S2. Load the user-level application module, call the application interface, and establish the mapping relationship between the DMA channel and the application interface;

[0008] S3. Data interaction is performed through corresponding channels or interfaces based on the mapping relationship.

[0009] According to one aspect of this application, the establishment of the mapping relationship between the DMA channel and the Netlink interface in step S2 is specifically as follows:

[0010] S21. Based on the device process, obtain the PID and establish a mapping between the PID and the DMA channel for the sending channel;

[0011] S22. Create a Netlink port and establish a mapping between the Netlink port and the DMA channel for the receive channel.

[0012] According to one aspect of this application, the user-layer application module in step S2 is responsible for providing a unified interface for control data requests and business data requests and distributing the data, specifically as follows:

[0013] S2a: Issue system configuration, initialize peripheral components of the device, and bring them into the expected working state.

[0014] S2b: Establish monitoring threads for all receiving channels to receive data sent from the MCDMA receiving channel.

[0015] S2c establishes a control data interface listening thread for communicating with the control system to receive and send control data.

[0016] S2d establishes a business data interface listening thread, which directly interacts with the network protocol stack and is responsible for receiving and sending business data.

[0017] According to one aspect of this application, step S3 specifically comprises:

[0018] S31. When the user layer application module sends data to the kernel MCDMA driver module, it calls the kernel driver layer to send the data to the kernel driver layer for processing. By looking up the mapping relationship between PID and DMA channel, the data is sent out through the specified DMA channel.

[0019] S32. When the user layer application module receives data from the kernel MCDMA driver module, it calls the kernel driver layer. The kernel driver layer receives DMA data through its receive channel. By looking up the mapping between the Netlink port and the DMA channel, it sends the data to the user layer application through the corresponding Netlink port. After receiving the data, the application distinguishes whether the data is control data or business data according to the port number and performs data distribution processing again.

[0020] According to one aspect of this application, step S23 is also included:

[0021] Step S23a: Construct a weight caching module and a weight assignment module adapted to the Netlink port, set weights for each data type in each application layer, and construct a weight set for the application layer to form a pre-configured data weight interface.

[0022] Step S23b: Construct a temporary data buffer to receive data sent or received by user layer applications to MCDMA through the Netlink interface. According to the data type, the weight of the corresponding data type is called by the weight buffer module in the weight buffer module through the weight assignment module, the priority of the data is recalculated and sorted to form the data to be sent.

[0023] Step S23c: Establish the mapping relationship between the data to be sent and the kernel driver layer, forming data queues with different priorities.

[0024] According to one aspect of this application, it also includes:

[0025] Step S23d: Construct a multi-threaded processing module, read the number of cores and frequency of the current device controller, call the pre-stored model, generate thread parameters, and form a predetermined number of threads; read the priority of the data to be sent, and allocate the corresponding data to each thread, and have the thread process the corresponding data to be sent.

[0026] According to one aspect of this application, it also includes:

[0027] Step S23e: Construct a batch processing module, call the data type of each message in each user layer application, read the length and composition of the data, and determine whether each piece of data can be combined into a whole based on the pre-stored rules; if so, package the data to be sent according to the rules and establish the association between the packaged data and the corresponding thread.

[0028] According to one aspect of this application, step S31 further includes:

[0029] An encryption module is constructed to connect to the kernel driver layer, and encryption identifiers are established for each message type. When receiving or sending data, the encryption identifier of each message is read, and the data is split according to the identifier. Data that needs to be encrypted is encrypted by the encryption module and then sent through the MCDMA controller.

[0030] Beneficial Effects: This invention provides a data interaction method between the application layer and MCDMA module on a Linux platform based on Netlink. It offers advantages such as simple implementation, full-duplex communication, and asynchronous caching. This allows data transmission not only to be initiated by the application layer but also by the kernel driver actively sending data to the application layer. Furthermore, Netlink's asynchronous buffering feature ensures that data sent is temporarily stored in the receiver's socket queue, eliminating the need to wait for the receiver to complete data reception. These technical advantages will be described in detail in the implementation section. Attached Figure Description

[0031] Figure 1 This invention relates to a block diagram of application layer and kernel driver layer modules.

[0032] Figure 2 This is a flowchart illustrating the process of receiving MCDMA data.

[0033] Figure 3 The flowchart shows the process of sending MCDMA data. Implementation

[0034] Typically, user-level applications use system calls, ioctl, and the / proc filesystem to interact with the kernel. These methods are all synchronous, and data transfer can only be initiated by the application layer. This paper describes another method for application-level applications to interact with the kernel: using the Netlink interface to handle data exchange between user-level applications and the MCDMA module.

[0035] The kernel MCDMA driver process establishes a mapping relationship between DMA channels and Netlink port numbers / PIDs. User-level applications can use Netlink ports / PIDs to interact with the corresponding DMA channels via Netlink data transfer.

[0036] User-level applications can use the standard Socket interface to interact with kernel threads for DMA data, simplifying the implementation of DMA data transmission and reception requirements at the application layer. This method also leverages Netlink's asynchronous buffering feature; data sent is temporarily stored in the receiver's Socket queue, eliminating the need to wait for the receiver to complete data reception.

[0037] like Figure 1 The diagram shown illustrates the application layer processes and kernel drivers involved in this method.

[0038] S1. Start the device, load the kernel MCDMA driver module, and initialize all DMA channels in the driver module;

[0039] S2. Load the user-level application module, call the application interface, and establish a mapping relationship between the DMA channel and the application interface; specifically, establishing the mapping relationship between the DMA channel and the Netlink interface involves:

[0040] S21. Based on the device process, obtain the PID and establish a mapping between the PID and the DMA channel for the sending channel;

[0041] S22. Create a Netlink port and establish a mapping between the Netlink port and the DMA channel for the receive channel.

[0042] After completing the above tasks, the kernel process enters a waiting state to process the incoming DMA data.

[0043] The user-layer application module is responsible for providing a unified interface for control data requests and business data requests, and for distributing the data. This mainly includes the following steps:

[0044] S2a: Issue system configuration, initialize peripheral components of the device, and bring them into the expected working state.

[0045] S2b: Establish monitoring threads for all receiving channels to receive data sent from the MCDMA receiving channel.

[0046] S2c establishes a control data interface listening thread for communicating with the control system to receive and send control data.

[0047] S2d establishes a business data interface listening thread, which directly interacts with the network protocol stack and is responsible for receiving and sending business data.

[0048] S3. Data interaction is performed through the corresponding channels or ports based on the mapping relationship.

[0049] When the user layer application module receives data from the kernel MCDMA driver module, the kernel driver layer receiving channel receives DMA data and, by querying the mapping relationship between the Netlink port and the DMA channel, sends the data to the upper layer application through the corresponding Netlink port. After receiving the data, the application distinguishes whether the data is control data or business data according to the port number and performs data distribution processing again.

[0050] This method describes another approach for data interaction between the application layer and the kernel, namely, using the Netlink interface to realize data interaction processing between user layer applications and the MCDMA (Multi-channel Direct Memory Access) module.

[0051] like Figure 2 The diagram shows the process of a user-level application receiving MCDMA data. In the kernel driver, the MCDMA driver thread's receiving and processing logic can distinguish which DMA channel the data comes from by using the TID identifier. Then, by querying the mapping relationship between the Netlink port and the DMA channel, the data is sent to the upper-layer application through the corresponding Netlink port.

[0052] When the user layer application module sends data to the kernel MCDMA driver module, the data is sent to the kernel driver layer for processing through the pre-established PID and DMA channel mapping relationship. The kernel driver layer obtains the data and sends it to the FPGA device through the specified DMA channel by looking up the mapping relationship.

[0053] like Figure 3The diagram illustrates the DMA data transmission process of an application via the Netlink interface. When sending Netlink messages to the kernel space, the application cannot distinguish data based on the Netlink port. Therefore, instead of using the Netlink port number, different controller values ​​(PID values) are set for the Netlink interface to differentiate DMA channels. We set the PID value corresponding to the channel to be the same as the Netlink port number. This method leverages the mapping relationship between Netlink port numbers and DMA channel numbers in the kernel thread, simplifying the query process in the driver. After receiving application data, the kernel driver uses the PID value to find the corresponding DMA channel and then sends the data to the FPGA for further processing through that channel.

[0054] This invention provides a method for data interaction between the application layer and MCDMA module of a Linux platform based on Netlink. The Netlink interface has advantages such as simple implementation, full-duplex communication, and asynchronous caching, which allows data transmission not only to be initiated by the application layer, but also by the kernel driver to actively initiate data transmission to the application layer. Moreover, Netlink's asynchronous buffering feature allows data to be temporarily stored in the receiver's socket queue after it is sent, without waiting for the receiver to complete data reception.

[0055] According to one aspect of this application, step S23 is also included:

[0056] Step S23a: Construct a weight caching module and a weight assignment module adapted to the Netlink port, set weights for each data type in each application layer, and construct a weight set for the application layer to form a pre-configured data weight interface.

[0057] By assigning weights to each data type within each application layer and constructing a weight set for each application layer, a pre-configured data weight interface is formed. This allows for priority sorting based on different data types during data transmission, thereby improving data transmission efficiency. By building a weight caching module and a weight assignment module adapted to the Netlink port, different weight values ​​can be flexibly set according to actual needs, thus meeting the requirements of different scenarios. The pre-configured data weight interface and weight set facilitate the management and maintenance of priority relationships between different data types. Based on a modular design philosophy, it is therefore easy to expand with new functional modules or modify existing ones.

[0058] Step S23b: Construct a temporary data buffer to receive data sent or received by user-layer applications to MCDMA via the Netlink interface. Based on the data type, the weight assignment module calls the weight cache module within the weight buffer module to assign the corresponding weights for that data type, recalculates the data priority, and sorts the data to form a queue of data to be sent. By establishing a temporary data buffer and calling the corresponding weight cache module based on the data type, and then recalculating and sorting the data to form a queue of data to be sent, the system response speed can be improved. By establishing a mapping relationship between the data to be sent and the kernel driver layer, forming queues of data to be sent with different priorities, the correctness of the sending order can be guaranteed. By prioritizing and establishing a mapping relationship for the data to be sent, the reliability and correctness of data transmission can be guaranteed.

[0059] Step S23c: Establish the mapping relationship between the data to be sent and the kernel driver layer, forming data queues with different priorities.

[0060] According to one aspect of this application, it also includes:

[0061] Step S23d: Construct a multi-threaded processing module, read the number of cores and frequency of the current device controller, call the pre-stored model, generate thread parameters, and form a predetermined number of threads; read the priority of the data to be sent, and allocate the corresponding data to each thread, and have the thread process the corresponding data to be sent.

[0062] By constructing a multi-threaded processing module, the advantages of multi-core CPUs can be leveraged to improve the system's concurrency and processing efficiency. By reading the number of cores and frequency of the current device controller and calling pre-stored model parameters to generate a predetermined number of threads, device resources can be fully utilized, improving data processing speed. Since this solution generates thread parameters based on pre-stored models, different thread numbers and parameters can be flexibly set according to actual needs, improving the solution's flexibility and achieving excellent results in various scenarios.

[0063] According to one aspect of this application, it also includes:

[0064] Step S23e: Construct a batch processing module. This module calls the data type of each message from each user-level application, reads the data length and composition, and determines whether the data can be combined into a single unit based on pre-stored rules. If so, it packages the data to be sent according to the rules and establishes an association between the packaged data and the corresponding thread. By constructing a batch processing module, multiple data packets can be combined into a single unit, thereby reducing the number of network transmissions and improving data transmission efficiency. By establishing an association between the packaged data and the corresponding thread, the advantages of multi-core CPUs can be fully utilized, improving the system's concurrency and processing efficiency. Because this solution determines whether the data can be combined into a single unit based on pre-stored rules and packages the data to be sent according to the rules, different rules and packaging methods can be flexibly set according to actual needs. By packaging the data to be sent and establishing an association between the packaged data and the corresponding thread, the reliability and correctness of data transmission can be guaranteed.

[0065] According to one aspect of this application, step S31 further includes:

[0066] An encryption module is constructed to connect to the kernel driver layer, and encryption identifiers are established for each message type. When receiving or sending data, the encryption identifier of each message is read, and the data is split according to the identifier. Data that needs to be encrypted is encrypted by the encryption module and then sent through the MCDMA controller.

[0067] Because some applications contain highly sensitive messages, encrypted transmission is required. Therefore, the above embodiment is provided. The encryption module is primarily responsible for encrypting the data that needs encryption and transmitting the encrypted data to the MCDMA controller for sending. This module is also responsible for managing and maintaining encryption identifiers for different message types.

[0068] A unique encrypted identifier is established for each message type to facilitate data routing during reception or transmission. The specific process is as follows: For each message type, a unique encrypted identifier is generated; the generated encrypted identifier is stored in the kernel driver layer.

[0069] Read the encryption identifier of each message and process it in a split stream: When receiving or sending data, the data is split according to the encryption identifier of each message. The specific process is as follows: Retrieve the data to be sent or received from the buffer; determine whether the current data needs to be encrypted according to the pre-stored rules; if encryption is required, transmit the data to be sent or received to the encryption module for processing; after encryption, transmit the data to be sent or received through the MCDMA controller. Clean up resources during encryption and decryption: After processing the data to be sent or received, it is necessary to clean up the resources it occupies, including the buffer and encryption module.

[0070] Specific implementation examples are given below for the above implementation scheme.

[0071] In one embodiment of this application:

[0072] 1. The application creates a Netlink socket and specifies the required protocol family and type.

[0073] 2. Applications use the setsockopt function to set socket options to enable or disable message filtering and broadcasting.

[0074] 3. The application sends a request message to the kernel and waits for the kernel to return a result. If filtering is enabled, only response messages that meet the criteria will be received; if broadcasting is enabled, multiple response messages may be received.

[0075] 4. After receiving the request message, the kernel processes it according to the protocol family and type, assembles the message into a channel baseband frame data format, and sends it through the corresponding DMA transmission channel.

[0076] 5. After receiving the corresponding data from the channel, the end station device sends the data from kernel space to user space, where the application processes the message and generates a reply message. If the message is a broadcast message, all end station devices will receive and process the message.

[0077] 6. The terminal device sends data from user space to kernel space, and then sends it to the channel via the DMA channel for transmission.

[0078] 7. After receiving data from the channel, the master station device extracts the message from the channel data and sends the message to the application. Upon receiving the message returned by the kernel, the application parses the data and performs corresponding processing. If broadcast functionality is enabled, it may be necessary to merge and deduplicate multiple reply messages.

[0079] 8. The application can continue to send request messages to the kernel or close the Netlink socket.

[0080] In one embodiment of this application,

[0081] 1. The application creates a Netlink socket and specifies the required protocol family and type.

[0082] 2. The application creates multiple worker threads and associates each thread with a Netlink socket.

[0083] 3. The application sends multiple request messages to the kernel and waits for the kernel to return the results. Each worker thread is responsible for processing a portion of the request messages and saving the results to shared memory.

[0084] 4. After receiving the request message, the kernel processes it according to the protocol family and type, assembles the message into a channel baseband frame data format, and sends it through the corresponding DMA transmission channel.

[0085] 5. After receiving the corresponding data from the channel, the terminal station equipment parses the data and sends it to the application for processing.

[0086] 6. The application can continue to send request messages to the kernel, or shut down the Netlink socket and worker threads.

[0087] In one embodiment of this application,

[0088] 1. The application creates a Netlink socket and specifies the required protocol family and type.

[0089] 2. The application uses the setsockopt function to set socket options to enable TLS / SSL encryption and authentication.

[0090] 3. The application sends a request message to the kernel, assembles the message into a channel baseband frame data format, and sends it through the corresponding channel via the corresponding DMA transmission channel.

[0091] 4. After receiving the corresponding data from the channel, the end station device parses the data and performs the appropriate processing. The decryption operation is automatically completed by the TLS / SSL protocol, and the application does not need to concern itself with the specific implementation details.

[0092] 5. The application can continue to send request messages to the kernel or close the Netlink socket.

[0093] The preferred embodiments of the present invention have been described in detail above. However, the present invention is not limited to the specific details in the above embodiments. Within the scope of the technical concept of the present invention, various equivalent transformations can be made to the technical solutions of the present invention, and these equivalent transformations all fall within the protection scope of the present invention.

Claims

1. A method for data interaction between an application layer of a Netlink-based Linux platform and a MCDMA module, characterized in that, The method comprises the following steps: S1, starting the device, loading the kernel MCDMA driver module, and initializing all DMA channels in the driver module; S2, loading the user layer application module, calling the application interface, and establishing a mapping relationship between the DMA channel and the application interface; S3, based on the mapping relationship, data interaction is carried out through the corresponding channel or interface; The step S2 of establishing the mapping relationship between the DMA channel and the application interface is specifically: S21, based on the process of the device, obtaining the PID, and establishing the PID and the DMA channel mapping for the sending channel; S22, creating a Netlink port, and establishing the Netlink port and the DMA channel mapping for the receiving channel; The step S2 further comprises that the user layer application module further provides a unified interface for the control data request and the service data request and carries out data distribution, and the specific steps are as follows: S2a, issuing system configuration, initializing the device peripheral components and entering the expected working state; S2b, establishing all receiving channel monitoring threads for receiving the data sent by the MCDMA receiving channel; S2c, establishing a control data interface monitoring thread for communicating with the control system and receiving and sending control data; S2d, establishing a service data interface monitoring thread, which directly interacts with the network protocol stack and is responsible for receiving and sending service data; The step S3 is further: S31, when the user layer application module sends data to the kernel MCDMA driver module, the kernel driver layer is called, the data is sent to the kernel driver layer for processing, the data is sent out through the specified DMA channel by searching the PID and the DMA channel mapping relationship; S32, when the user layer application module receives the data of the kernel MCDMA driver module, the kernel driver layer is called, the receiving channel of the kernel driver layer receives the DMA data, and the data is sent to the user layer application through the corresponding Netlink port by searching the Netlink port and the DMA channel mapping, and the application program distinguishes whether the data is control data or service data according to the port number after receiving the data, and carries out data distribution processing again.

2. The method of claim 1, wherein the Netlink-based data interaction between the Linux platform application layer and the MCDMA module is characterized by, Further comprising step S23: Step S23a, constructing a weight buffer module and a weight assignment module adapted to the Netlink port, setting a weight for each data type of each application layer, and constructing a weight set for the application layer to form a preconfigured data weight interface; Step S23b, constructing a temporary data buffer area for receiving the data sent or received by the user layer application to the MCDMA through the Netlink interface, calling the weight of the corresponding data type in the weight buffer module in the weight assignment module according to the data type, recalculating the priority of the data and sorting, and forming the to-be-sent data; Step S23c, establishing a mapping relationship between the to-be-sent data and the kernel driver layer to form a to-be-sent data queue with different priorities.

3. The method of claim 2, wherein the Netlink-based data interaction between the Linux platform application layer and the MCDMA module is characterized by, Further comprising: Step S23d, constructing a multi-thread processing module, reading the number and frequency of the cores of the current device controller, calling the pre-stored model, generating thread parameters, forming a predetermined number of threads; reading the priority of the data to be sent, and assigning the corresponding data to each thread, and processing the corresponding to-be-sent data by the thread.

4. The method of claim 3, wherein the Netlink-based data interaction between the application layer and the MCDMA module of the Linux platform comprises: Also includes: Step S23e, constructing a batch processing module, calling the data type of each message of each user layer application, reading the length and composition of the data, and judging whether each data can be combined into a whole based on the pre-stored rules; If so, the to-be-sent data is packed according to the rules, and the association between the packed data and the corresponding thread is established.

5. The method of claim 4, wherein the Netlink-based data interaction between the application layer and the MCDMA module of the Linux platform comprises: The step S31 further includes: Constructing an encryption module connected with the kernel driver layer data, and establishing an encryption identifier for each message type, reading the encryption identifier of each message when receiving or sending data, and performing shunt processing on the data according to the identifier, and sending the data through the MCDMA controller after the data that needs to be encrypted is encrypted through the encryption module.

Images