A method and system for establishing DPDK NAT translation entries

Abstract

This invention discloses a method and system for establishing DPDK NAT translation entries, comprising the following steps: Step 1, the DPDK packet forwarding subsystem sends the first packet that cannot hit the user space NAT translation entry to the LINUX kernel through the DPDKKNI interface; Step 2, the first packet processing module parses the packet header after receiving the first packet through the kernel KNI interface to form the source first IP 5-tuple information; This invention simplifies the system construction of DPDK-based NAT translation tables, making the process of establishing user space DPDK NAT translation entries very simple and efficient; Moreover, in this process, it is not necessary to modify the source code of the LINUX protocol stack, avoiding intrusive modifications to the LINUX protocol stack, enhancing the independence of the NAT entry establishment software, and the DPDK NAT processing software system established using this method can be directly deployed on the LINUX system without compiling and upgrading the LINUX kernel system, simplifying the deployment and application of DPDK-based NAT processing software.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, specifically to a method and system for establishing DPDK NAT translation entries. Background Technology

[0002] DPDK (Data Plane Development Kit) is an open-source data plane development toolkit. It's a high-performance packet processing software package provided by Intel to address packet processing performance issues in multi-core environments, running in user space. The DPDK software platform utilizes technologies such as operating system kernel bypass, polling-mode uninterrupted data transmission and reception, large page memory management, lock-free queues, zero-copy packets, and the Kernel Network Interface (KNI) to achieve high-performance packet transmission, reception, and processing capabilities in multi-core CPU environments.

[0003] DPDK is primarily used on the Linux operating system running on the x86 hardware platform. It does not provide a general-purpose protocol stack software in user space. When building specific business systems, secondary development based on DPDK is required to achieve high-performance business systems. In this secondary development, certain data packets or specific data packets from a single data traffic stream are often received by DPDK and sent to the Linux kernel for processing. The Linux kernel then processes the data packets and sends them back to DPDK, which then forwards them to other external systems. Alternatively, data packets generated by the Linux kernel are sent to DPDK by the kernel and then forwarded to other external systems by DPDK.

[0004] DPDK uses KNI (Kernel Network interface) to enable DPDK to send data packets to the Linux kernel and vice versa.

[0005] In some business message processing systems, in addition to transmitting message content via the KNI interface, DPDK and the Linux kernel also need to exchange message processing information, especially message analysis and processing results. This is meaningful for improving system processing performance and avoiding redundant analysis; sometimes it is even necessary. For example, when using DPDK to implement NAT translation message processing, to improve NAT message processing efficiency, a translation table is established in DPDK. When DPDK receives a message, it performs IP header resolution to obtain the IP 5-tuple (source IP, destination IP, source port, destination port, protocol number), and then performs a NAT translation table lookup. If the match is found, the message is translated and sent out; otherwise, it is transmitted to the Linux kernel protocol stack for processing. After the kernel protocol stack completes the NAT translation, it transmits the data packet back to DPDK, which then sends it out. In this process, DPDK has already performed packet header parsing. If DPDK passes the header parsing result to the Linux kernel protocol stack when sending the packet, the Linux kernel protocol stack can directly use the header parsing result, avoiding repeated header parsing—this is an optimization. Furthermore, after Linux completes NAT translation, a new packet header is formed. At this point, the IP header's 5-tuple has changed. After receiving the packet from the Linux kernel, DPDK can only obtain the new IP header, but cannot obtain the source IP 5-tuple based on this packet. Therefore, the Linux kernel protocol stack needs to pass the source 5-tuple information of this packet to DPDK so that DPDK can build NAT entries based on the source 5-tuple and the new 5-tuple information. This is an example of the necessity for the Linux kernel to pass kernel processing results to DPDK. In these two examples, we collectively refer to the packet header parsing structure that DPDK needs to pass to the Linux kernel, and the packet source IP 5-tuple information that the Linux kernel needs to pass to DPDK, as packet "processing information."

[0006] NAT (Network Address Translation) is a technology primarily used to address the problem of insufficient IP addresses. With the help of NAT, when a private (reserved) internal network sends data packets through a router (or gateway, NAT device, etc.), the private addresses are translated into legitimate IP addresses. A local area network (LAN) only needs a minimum of one public IP address to meet the communication needs of all computers within the private address network with the Internet. To achieve this, NAT translation tables need to be established in the relevant systems or devices to record the mapping between the internal network (source IP, source port) and the public network (source IP, source port). The NAT translation table is established triggered by the first packet sent from the internal network to the public network when accessing a specific target; for IP packets entering the private network from the outside, it is usually established based on specified rules. After the NAT translation table is established, when traffic is sent from the internal network to the public network, the IP packet will look up the NAT translation table based on (source IP, source port) to realize the translation from internal network (source IP, source port) to public network (source IP, source port). For the returning IP packet, the NAT translation table will look up the entry for internal network (source IP, source port) based on the public network (destination IP, destination port) of the IP packet and realize the translation of destination IP and destination port.

[0007] In the Linux operating system, NetFilter, implemented using the kernel protocol stack, handles the creation and maintenance of the aforementioned NAT translation tables. Linux also utilizes the IPTables tool, which provides convenient options for configuring and viewing NAT translation tables. However, Linux's NAT forwarding performance is relatively low.

[0008] With the advent of DPDK, NAT forwarding technologies based on the DPDK software platform emerged in the industry, significantly improving NAT forwarding performance. NAT forwarding technologies based on the DPDK software platform typically employ a user-space protocol stack, meaning that network protocol stack processing software is built in the Linux user space, and NAT forwarding entries are constructed and NAT translation is performed within this user-space protocol stack processing software. Furthermore, it is necessary to develop related utility software for NAT rule configuration, information viewing, and maintenance based on the user-space protocol stack.

[0009] The NAT forwarding table built on the DPDK software platform requires building the protocol stack software in user space. This necessitates maintaining both the user space protocol stack system and the Linux kernel protocol stack system, as well as developing software tools for configuring rules, viewing entries, and maintaining the NAT forwarding table based on the user space protocol stack. This significantly increases the complexity and development difficulty of the system. Summary of the Invention

[0010] The purpose of this invention is to provide a method and system for establishing DPDK NAT translation entries, so as to solve the problem that when building a NAT forwarding table based on the DPDK software platform, it is necessary to maintain two sets of protocol stacks at the same time, namely the user space protocol stack and the LINUX kernel protocol stack, so as to significantly reduce the complexity and development difficulty of the system.

[0011] To achieve the above objectives, the present invention provides the following technical solution: a system for establishing DPDK NAT translation entries, comprising: a first packet processing module and a second packet processing module;

[0012] The first message processing module is located in the LINUX kernel space and is an extension of the DPDK KNI module. The first message processing module can perform message header analysis and establish first NAT translation information, and can send the first NAT translation information along with the message to the user space program through the KNI interface.

[0013] The second message processing module is located in the LINUX user space DPDK system and is an extension program of the user space DPDK system. The second message processing module can parse the first NAT translation information from the message received from the KNI interface and establish a NAT forwarding table entry in the user space based on the first NAT translation information.

[0014] A method for establishing DPDK NAT translation entries includes the following steps:

[0015] Step 1: The DPDK packet forwarding subsystem sends the first packet that cannot hit the user space NAT translation table entry to the LINUX kernel through the DPDK KNI interface;

[0016] Step 2: After receiving the first message through the kernel KNI interface, the first message processing module parses the message header to form the source first IP 5-tuple information;

[0017] Step 3: Then the first message is handed over to the kernel protocol stack for NAT translation to form the second message;

[0018] Step 4: The kernel protocol stack sends the second packet to the DPDK packet forwarding subsystem through the KNI interface. Before the second packet is sent out from the KNI interface, the first packet processing module performs header parsing on the second packet to form the target second IP five-tuple information.

[0019] Step 5: The first message processing module combines the first IP 5-tuple information and the second IP 5-tuple information to form the first NAT translation information, and packages the first NAT translation information and the second message together to form the third message;

[0020] Step 6: Send the third message to the DPDK message forwarding subsystem via the KNI kernel-mode module;

[0021] Step 7: The second message processing module parses the first NAT translation information from the third message received from the KNI interface, and then establishes a NAT translation entry in the user space based on the first NAT translation information.

[0022] The first message processing module is formed by extending the DPDK KNI kernel-mode module, without modifying the LINUX kernel and kernel protocol stack.

[0023] Specifically, the first message processing module parses the message header immediately before the DPDK KNI kernel-mode module receives the first message from the KNI interface and is about to hand it over to the kernel protocol stack for processing, forming the first IP 5-tuple information, and stores the first IP 5-tuple information in the internal buffer of the first message processing module.

[0024] Before sending a message through the KNI interface, the first message processing module searches for the corresponding first IP 5-tuple information in the internal buffer of the first message processing module through the second message, and then constructs the first NAT translation information based on the first IP 5-tuple information and the second IP 5-tuple information.

[0025] The first NAT translation information is formed by fixing a 4-byte magic word, and then buffering and concatenating the fixed-length first IP 5-tuple information and the second IP 5-tuple information after the magic word.

[0026] The third message stores the first NAT translation information directly before the link layer header of the second message.

[0027] When the second message processing module parses the third message, it first checks whether the 4 bytes of the message header are the same as the agreed magic word. If they are the same, it continues to parse the fixed-length first IP 5-tuple information and the second IP 5-tuple information, and removes the first NAT translation information from the third message to restore the second message.

[0028] Compared with the prior art, the beneficial effects of the present invention are:

[0029] This invention uses a user-space DPDK packet processing program to send a first packet that cannot find a NAT forwarding table entry to the LINUX kernel via the DPDK KNI interface. A kernel-space DPDK KNI interface extension program analyzes the packet headers and constructs first NAT translation information during packet reception and transmission via the DPDK KNI interface. This first NAT translation information is then packaged with a second packet to form a third packet, which is sent to the user-space program via the KNI interface. The user-space DPDK extension program parses the first NAT translation information from the third packet and establishes a user-space NAT forwarding table entry based on this information. This method simplifies the construction of DPDK-based NAT translation tables, making the creation of user-space DPDK NAT translation table entries very simple and efficient. Moreover, this process does not require modification of the Linux protocol stack source code, avoiding intrusive modifications to the Linux protocol stack and enhancing the independence of the NAT entry creation software. The DPDK NAT processing software system built using this method can be directly deployed on a Linux system without compiling and upgrading the Linux kernel system, simplifying the deployment and application of DPDK-based NAT processing software. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the KNI software configuration of the present invention;

[0031] Figure 2 This is a schematic diagram of the software system for establishing the DPDK NAT translation table of the present invention;

[0032] Figure 3 This is a schematic diagram illustrating the process of establishing DPDK NAT translation entries in this invention;

[0033] Figure 4 This is a schematic diagram of the formation of the third message of the present invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] like Figure 2 As shown, the system for establishing DPDK NAT translation entries provided in this application includes: a first message processing module 110 and a second message processing module 230;

[0036] The first message processing module 110 is located in the LINUX kernel space and is an extension of the DPDK KNI kernel-mode module 100. The first message processing module 110 can perform message header analysis and establish first NAT translation information, and can send the first NAT translation information along with the message to the user space program through the KNI interface.

[0037] The second message processing module 230 is located in the LINUX user space DPDK system and is an extension of the user space DPDK software system 200. The second message processing module 230 can parse the first NAT translation information from the message received from the KNI interface and establish a NAT forwarding table entry in the user space based on the first NAT translation information.

[0038] The DPDK KNI interface and its software are the important technical background for the implementation of this patent.

[0039] KNI (Kernel Network Interface) is a virtual network interface. It serves as the channel for data packet exchange between the DPDK software system's Linux user space program and the Linux kernel. From the perspective of the Linux kernel and kernel protocol stack, the KNI interface is the same as a regular network interface, capable of sending and receiving data packets. It also possesses the packet statistics, filtering, and packet capture capabilities common to ordinary Linux interfaces.

[0040] like Figure 1As shown, the KNI implementation consists of two parts: the KNI kernel-mode module 100 and the KNI user-mode module 220. They interact with each other via queue 300, which transmits pointers to the packets. Therefore, there is no performance overhead associated with `copy_to_user()` and `copy_from_user()` methods present in typical Linux user-mode and kernel-mode communication. The KNI user-mode module uses a `struct rte_mbuf` data structure (i.e., the message description structure of the DPDK system, abbreviated as MBuf) instance to carry the packet, placing the MBuf instance into the queue. The KNI kernel-mode module retrieves the MBuf data structure instance from the queue and then converts it into a `struct sk_buff` data structure (the message description structure used in the Linux kernel, abbreviated as SKB) instance, thus enabling the user space to send packets to the kernel space. This process is called the internal KNI module receiving packets. Conversely, the KNI kernel-mode module converts the SKB instance into an MBuf instance and places the MBuf instance into a queue. The KNI user-mode module then retrieves the MBuf from the queue, thereby enabling the kernel space to send messages to the user space. This process is referred to as sending messages through the KNI module. In the DPDK software system, the MBuf in kernel space is a struct rte_kni_mbuf data structure, and the one in user space is a struct rte_mbuf data structure. The DPDK software system performs conversions between these two structures when communicating between user space and kernel space; in this scheme, they are both simplified and referred to as MBuf.

[0041] The SKB instance is passed through multiple protocol stack layers during the Linux kernel protocol stack processing. SKB->head points to the header of its data area, and SKB->data points to the header of its message data. During processing, SKB->data may be modified or the buffer pointer may be moved, but SKB->head will not change.

[0042] like Figure 3 As shown, this application provides a method for establishing DPDK NAT translation entries. When the DPDK packet forwarding subsystem receives a first packet from an external network interface, assuming it is entering the system for the first time, the NAT translation table in the DPDK packet forwarding subsystem will not have a translation entry for this packet, thus the first packet cannot match the NAT translation table. Based on the solution of this application, the NAT forwarding table entries in the DPDK packet forwarding subsystem will be established based on the following process: including the following steps:

[0043] Step 1: The DPDK packet forwarding subsystem sends the first packet that does not hit the user space NAT translation table entry to the LINUX kernel through the DPDK KNI interface. That is, the DPDK packet forwarding subsystem 210 will send packets that do not hit the NAT translation table entry to the LINUX kernel for processing through the KNI interface.

[0044] Step 2: The first message processing module 110 obtains the first IP 5-tuple of the first message. That is, after receiving the first message through the kernel KNI interface, the first message processing module 110 parses the message header to form the source first IP 5-tuple information.

[0045] Step 3: Then the first packet is handed over to the LINUX kernel protocol stack 300 for NAT translation to form the second packet. That is, after the LINUX kernel protocol stack 300 completes the IP address translation of the header of the first packet, it generates the second packet SKB2. The IP 5-tuple in the header of the SKB2 packet is the 5-tuple after NAT translation. The LINUX kernel sends the second packet SKB2 to the user space DPDK packet forwarding subsystem 210 through the KNI interface.

[0046] Specifically, after the conversion from MBuf to SKB is completed in the KNI kernel module kni_net_rx_normal() function, the SKB packet of the first packet, namely SKB1, is obtained. The KNI kernel module will perform header parsing on the SKB1 packet before calling the LINUX kernel packet receiving function netif_rx_ni() to obtain the first IP 5-tuple information. The first packet processing module 110 stores the first IP 5-tuple information in its internal buffer. When storing the first IP 5-tuple information, it also stores the buffer pointer of SKB1, namely the SKB1->head field.

[0047] Step 4: The kernel protocol stack sends the second packet to the DPDK packet forwarding subsystem through the KNI interface. Before the second packet is sent out from the KNI interface, the first packet processing module 110 performs header parsing on the second packet to form the target second IP 5-tuple information. That is, in the kni_net_tx() function of the KNI kernel mode module, the first packet processing module 110 first parses the SKB2 header of the second packet to obtain the second IP 5-tuple.

[0048] Step 5: The first packet processing module 110 combines the first IP 5-tuple information and the second IP 5-tuple information to form the first NAT translation information, and then packages the first NAT translation information and the second packet together to form the third packet. Specifically, the first packet processing module 110 searches for the first IP 5-tuple corresponding to SKB2 (i.e., the source 5-tuple of SKB2) in multiple first IP 5-tuple cache data based on the SKB2->head field; then, the first packet processing module 110 packages the second IP 5-tuple and the second packet together to form the third packet. The specific packaging method is as follows: Figure 4 As shown, the second message SKB2->data is subjected to the skb_push() operation, which means moving the data area of ​​SKB2 32 bytes to the header. In this 32-byte data buffer, a 4-byte magic word integer (0xF1E2D3C4), a 14-byte first IP quintuple, and a 14-byte second IP quintuple are copied to form the third message SKB3.

[0049] Step 6: The third packet is sent to the DPDK packet forwarding subsystem 210 through the KNI kernel mode module 100. That is, the KNI kernel mode module 100 converts SKB3 into an MBuf instance and puts it into the queue. The KNI user mode module 220 receives the MBuf instance from the queue and hands it over to the DPDK packet forwarding subsystem 210 for processing.

[0050] Step 7: The second message processing module 230 parses the first NAT translation information from the third message received from the KNI interface, and then establishes a user-space NAT translation entry based on the first NAT translation information. Specifically, the DPDK message processing subsystem 210 hands over the MBuf instance to the second message processing module 230 for processing. The second message processing module 230 analyzes the third message header of the data area of ​​the MBuf instance, that is, first checks whether the first 4 bytes are the agreed magic word (such as 0xF1E2D3C4). If so, the data area header of the MBuf instance contains 32 bytes of first NAT translation information. Then, based on this first NAT translation information, a user-space NAT translation entry is established and the NAT translation entry is installed. The second message processing module 230 also removes the first 32 bytes from the data area of ​​the MBuf instance to restore the second message for continued forwarding processing.

[0051] The first message processing module is formed by extending the DPDK KNI kernel-mode module, without modifying the LINUX kernel and kernel protocol stack.

[0052] Specifically, the first message processing module parses the message header immediately before the DPDK KNI kernel-mode module receives the first message from the KNI interface and is about to hand it over to the kernel protocol stack for processing, forming the first IP 5-tuple information, and stores the first IP 5-tuple information in the internal buffer of the first message processing module.

[0053] Before sending a message through the KNI interface, the first message processing module searches for the corresponding first IP 5-tuple information in the internal buffer of the first message processing module through the second message, and then constructs the first NAT translation information based on the first IP 5-tuple information and the second IP 5-tuple information.

[0054] The first NAT translation information is formed by fixing a 4-byte magic word, and then buffering and concatenating the fixed-length first IP 5-tuple information and the second IP 5-tuple information after the magic word.

[0055] The third message stores the first NAT translation information directly before the link layer header of the second message.

[0056] When the second message processing module parses the third message, it first checks whether the 4 bytes of the message header are the same as the agreed magic word. If they are the same, it continues to parse the fixed-length first IP 5-tuple information and the second IP 5-tuple information, and removes the first NAT translation information from the third message to restore the second message.

[0057] Furthermore, a 4-byte magic word (e.g., 0xF1E2D3C4) in the header indicates that the MBuf data area includes the first NAT translation information. The first three bytes of this magic word must not collide with the OUI (Organizationally Unique Identifier), because the first three bytes of the message processed by the DPDK software system are actually the OUI part of the MAC address. For security authentication, a longer magic word (e.g., 8 bytes) can be used as the identifier.

[0058] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for establishing DPDK NAT translation entries, characterized in that, Includes the following steps: Step 1: The DPDK packet forwarding subsystem sends the first packet that cannot hit the user space NAT translation table entry to the LINUX kernel through the DPDKKNI interface; Step 2: After receiving the first message through the kernel KNI interface, the first message processing module parses the message header to form the source first IP 5-tuple information; Step 3: Then the first message is handed over to the kernel protocol stack for NAT translation to form the second message; Step 4: The kernel protocol stack sends the second packet to the DPDK packet forwarding subsystem through the KNI interface. Before the second packet is sent out from the KNI interface, the first packet processing module performs header parsing on the second packet to form the target second IP five-tuple information. Step 5: The first message processing module combines the first IP 5-tuple information and the second IP 5-tuple information to form the first NAT translation information, and packages the first NAT translation information and the second message together to form the third message; Step 6: Send the third message to the DPDK message forwarding subsystem via the KNI kernel-mode module; Step 7: The second message processing module parses the first NAT translation information from the third message received from the KNI interface, and then establishes a NAT translation entry in the user space based on the first NAT translation information.

2. The method for establishing DPDK NAT translation entries according to claim 1, characterized in that: The first message processing module is formed by extending the DPDK KNI kernel-mode module, without modifying the LINUX kernel and kernel protocol stack.

3. The method for establishing DPDK NAT translation entries according to claim 1, characterized in that: The first message processing module parses the message header immediately before the DPDK KNI kernel-mode module receives the first message from the KNI interface and is about to hand it over to the kernel protocol stack for processing, forming the first IP 5-tuple information, and stores the first IP 5-tuple information in the internal buffer of the first message processing module.

4. The method for establishing DPDK NAT translation entries according to claim 1, characterized in that: Before sending a message through the KNI interface, the first message processing module searches for the corresponding first IP 5-tuple information in the internal buffer of the first message processing module through the second message, and then constructs the first NAT translation information based on the first IP 5-tuple information and the second IP 5-tuple information.

5. The method for establishing DPDK NAT translation entries according to claim 1, characterized in that: The first NAT translation information is formed by concatenating a 4-byte fixed-content magic word, a fixed-length first IP 5-tuple, and a second IP 5-tuple, with the first and second IP 5-tuples following the magic word.

6. The method for establishing DPDK NAT translation entries according to claim 1, characterized in that: The third message is formed by storing the first NAT translation information directly before the link layer header of the second message.

7. The method for establishing DPDK NAT translation entries according to claim 5, characterized in that: When the second message processing module parses the third message, it first checks whether the 4 bytes in the message header are the same as the agreed magic word. If they are the same, it continues to parse the fixed-length first IP 5-tuple information and the second IP 5-tuple information, and removes the first NAT translation information from the third message to restore the second message.

Images