Optimized kernel network and implementation method thereof

Abstract

The invention provides an optimized kernel network and an implementation method thereof, and relates to the technical field of kernel networks, the kernel network comprises a fast data channel component XDP arranged on a data link layer; when the network card equipment receives a message data packet, the XDP analyzes and filters the received data packet, or encapsulates or de-encapsulates the received data packet, and modifies a field to forward the data packet; and the XDP matches and filters the received data packet with the rules in the BPF Maps, and discards the data packet when the data packet is illegal. The method comprises the steps that hardware initialization comprises the step of adding a zero copy processing flow when an NAPI polling point processing function is added; the application program configures an XDP socket; the xsk unit executes a BPF instruction, calls a network card driving unit to configure an XSK cache pool, and establishes a DMA mapping relationship between the device and the UMEM shared cache; and the network card drives zero-copy receiving and receiving of the data packet. According to the invention, the kernel network communication efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of kernel network technology, and more specifically to an optimized kernel network and its implementation method. Background Technology

[0002] In traditional operating systems, the data plane (network processing functions) and control plane (kernel management and scheduling functions) are tightly coupled in network communication components, resulting in relatively low network communication efficiency. When applications send and receive data, they involve switching between user mode and kernel mode; when the operating system processes network packets, it involves data copying between kernel space and user space, as well as calls and returns at various layers of the TCP / IP protocol stack. This processing mode was fine in the era of low-speed network cards (10M / 100M), where applications spent most of their time waiting for data to be sent by the network card. However, in the era of gigabit networks, with data throughput increasing a hundredfold, the transmission and conversion of data between user mode and kernel mode can severely impact transmission and control efficiency in certain scenarios.

[0003] iptables / netfilter is a traditional firewall technology provided by Linux networks. It is highly scalable and could meet the needs of most network applications at the time. However, this framework also has many obvious problems: the netfilter framework is like an expert system that allows users to freely add policy rules, without any optimization or merging of added rules. This heavily relies on the operator's skill level. As the scale increases, the number of rules (n) grows exponentially, while packet processing has O(n) complexity, ultimately leading to a sharp decline in performance. With the increasing volume of internet traffic and the increasing power of network cards, the Linux kernel protocol stack had no problems in the era of slow 10Mbps / 100Mbps network cards, when applications spent most of their time waiting for data from the network card. Now, in the era of 1000Mbps / 10Gbps / 40Gbps network cards, data is received very quickly. The complex processing logic of the protocol stack becomes inefficient, clogging up a large number of packets in the kernel. From the perspective of kernel processing performance, when packets only need to be forwarded, too many processing rules waste a lot of CPU time, increase network latency, and reduce network throughput.

[0004] The netfilter framework operates at the IP layer. Packets need to pass through the link layer before being processed by the IP layer. Discarding packets wastes significant CPU resources and impacts overall performance. From the perspective of handling lost invalid packets, identifying packets that need to be discarded from the moment they are received at the link layer, rather than processing them at the IP layer, would undoubtedly reduce invalid packet processing time. Excessive matching rules can lengthen packet processing time; in extreme cases, a packet may need to iterate through all rules to find a match, severely impacting packet processing performance.

[0005] DPDK is a user-space data plane development kit initiated by Intel. This kit completely bypasses the kernel, running in user space and directly handing over network hardware to user-space network applications. It requires exclusive use of one or more CPUs. Because DPDK completely bypasses the kernel, it is difficult to integrate with existing systems, and upper-layer applications must reimplement mature kernel modules in user space, including routing tables and higher-level protocol stacks. Summary of the Invention

[0006] In view of this, the present invention provides an optimized kernel network, comprising: a Fast Data Path Component (XDP) and Berkeley Packet Filter Maps (BPF Maps) disposed at the data link layer; wherein, BPF Maps are used for key-value pair storage and serve as a communication medium between the application and XDP; the application predefines rules in BPF Maps. When a network interface card (NIC) device receives network data packets, XDP parses the received packets and filters them according to rules, or encapsulates or decapsulates the received packets, modifies fields, and forwards the packets; specifically including: XDP sends message packets directly to the application through its XSK unit; XDP requests a socket buffer (SKB), stores the packet data in the SKB, and then sends it to the kernel network protocol stack for processing. XDP redirects message packets to other CPUs or network interface cards. XDP matches message packets against rules in BPF Maps to filter message packets, and discards message packets that are invalid; XDP stores packet statistics in BPF Maps, and applications can access packet statistics by accessing BPF Maps.

[0007] Furthermore, XDP includes: a network interface card driver unit, a BPF-XDP packet filtering unit, a DMA unit, and an XSK unit; wherein: The network interface card (NIC) driver unit includes multiple link layer interfaces for NIC device hardware initialization, packet and data packet reception, and packet and data packet transmission. The DMA unit is used to provide data transfer between the network interface card (NIC) device and the memory, as well as between different memory locations. The XSK unit is used to establish a channel between the application and the kernel, and to transfer the packet data of the network card device to the application by using memory mapping and fast data channel technology. The BPF-XDP packet filtering unit is used to filter the packet data received by the network card driver unit and perform redirection and kernel protocol stack operations based on the returned results. The network interface card (NIC) driver unit has multiple link layer interfaces, including: a first interface for executing BPF commands, a second interface for configuring the XSK buffer pool, a third interface for NIC driver BPF XDP, a fourth interface for zero-copy receiving of packet data, a fifth interface for NIC driver zero-copy sending of packet data, a sixth interface for NIC hardware enabling, and a seventh interface for initializing the DMA description ring.

[0008] This invention also provides a method for kernel network optimization, employing the kernel network described above, the method comprising the following steps: Step 1, hardware initialization, includes: setting the MAC address, setting the MTU, and adding the NAPI polling point processing function; among them, a zero-copy processing procedure is added when adding the NAPI polling point processing function; Step 2: The application configures the XDP socket; the xsk unit executes BPF instructions, calls the network card driver unit to configure the XSK cache pool, and establishes the DMA mapping relationship between the device and the UMEM shared cache; Step 3, zero-copy reception of network card driver messages; in the zero-copy reception process, the messages read from the hardware through the DMA mechanism are stored in the UMEM shared memory; Step 4: The application copies the packets to the kernel space cache through the XSK unit. The network card driver unit processes the received packets through the NAPI polling packet sending and processing interface, and then caches the data packets and synchronizes them to the network card device through the DMA unit.

[0009] This invention enables the kernel to perform targeted high-speed processing on data packets when they arrive at L2 (network card driver layer), without having to "follow the rules" and enter the TCP / IP protocol stack, thereby improving the efficiency of kernel network communication. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the specific embodiments of the present invention, the drawings used in the description of the specific embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0011] Figure 1 This is a diagram of the XDP network component architecture of the present invention; Figure 2 This is a diagram showing the composition of the XDP sub-component of the data link layer in this invention. Figure 3 This is a flowchart of the network card driver bpf instruction execution process of the present invention; Figure 4 Flowchart of configuring cache pool for network card driver in this invention; Figure 5 This is a flowchart of the BPF XDP network card driver program execution process of the present invention; Figure 6 This is a flowchart of the network card data zero-copy receiving process of the present invention; Figure 7 This is a flowchart of the zero-copy transmission process of the network card driver according to the present invention; Figure 8 This is a flowchart illustrating the hardware startup process of the network card according to the present invention. Figure 9 This is a flowchart of the initialization DMA descriptor ring of the present invention; Figure 10 This is a flowchart of the initialization process for the RX descriptor ring of the present invention; Figure 11 This is a flowchart of the network card hardware initialization process of the present invention; Figure 12 This is a flowchart of the XDP socket configuration process of the present invention; Figure 13 This is a flowchart of the zero-copy message receiving process of the present invention; Figure 14 This is a flowchart illustrating the message sending process of the present invention. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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.

[0013] I. Overall Plan like Figure 1 As shown, the kernel program (XDP: eXpress Data Path) implemented in this invention runs on the early receive path of the link layer (network driver layer). When network hardware (such as network card device) receives network packets, the XDP kernel program parses the data packets, filters them according to rules, or encapsulates or decapsulates the data packets, modifies fields, and forwards the data packets.

[0014] The packet is sent to the application via XDP's XSK (Xdp SocKet, XDP socket). The XDP program requests an sk_buff (socket buff) structure to buffer the packet, stores it in the structure, and then sends it to the kernel network protocol stack for processing. The XDP program supports redirecting packets to other CPUs or network cards. If the message is determined to be an illegal message, the XDP program will discard it.

[0015] BPF Maps are used for key-value pair storage. They serve as a communication medium between applications and kernel-mode XDP programs, as well as between kernel-mode XDP programs, similar to shared memory access in inter-process communication.

[0016] The application predefines rules in BPF Maps, and the XDP program filters packets by matching the rules in the BPF Maps.

[0017] The XDP program stores packet statistics in Maps, and applications can access BPF Maps to obtain packet statistics.

[0018] The network components mainly include the XDP sub-component of the data link layer (network driver layer). The functions implemented by the XDP sub-component of the data link layer are described in detail below.

[0019] Data link layer XDP sub-components, such as Figure 2 As shown, it includes: a network interface card (NIC) driver unit, a BPF-XDP packet filtering unit, a DMA unit, and an XSK unit. The main functions of each unit are: Network interface card (NIC) driver unit: Includes multiple link layer interfaces, responsible for basic functions such as NIC hardware initialization, packet reception, and packet transmission, and is the foundation for realizing network functions.

[0020] DMA Unit: DMA is used to provide high-speed data transfer between network hardware and memory, as well as between memory devices. Data can be transferred quickly via DMA without CPU operation.

[0021] XSK Unit: The XSK unit, also known as the AF_XDP socket unit, establishes a channel between the application and the kernel, enabling fast transmission of network device data packets to the application through technologies such as memory mapping and XDP.

[0022] The BPF-XDP packet filtering unit's main function is to filter data packets received by the network card driver unit and perform operations such as redirection and sending kernel protocol stack based on the returned results.

[0023] The network card driver unit mainly implements XDP features based on existing functions.

[0024] The DMA unit and XSK unit inherit existing code, while the BPF-XDP packet filtering unit needs to be customized according to the application scenario.

[0025] II. Link Layer Interface Design 1. stmmac_bpf function Function prototype: int stmmac_bpf(struct net_device dev, struct netdev_bpf bpf) The parameters / return values ​​are shown in Table 1: Table 1. Parameters / Return Values ​​of the stmmac_bpf Function

[0026] Program logic: like Figure 3 As shown, the `stmmac_bpf` function is used to execute BPF commands. The `bpf` parameter carries command-related arguments, and the `bpf_netdev_command` enumeration type lists the types of BPF commands, including setting up the BPF program and building the XSK cache pool. When setting up the BPF program, if the program is running, hardware resources need to be released, and then the opening procedure needs to be re-executed. The opening procedure is shown in the `stmmac_open` function. For creating the XSK cache pool, see the `stmmac_xdp_setup_pool` function.

[0027] When executing a BPF command, relevant command parameters are required. The netdev_bpf structure is a structure for BPF command parameters, which includes data such as the BGP program and the XSK cache pool pointer.

[0028] The enumeration type bpf_netdev_command represents the supported BPF command types. In this invention, the two types XDP_SETUP_PROG and XDP_SETUP_XSK_POOL are mainly used, which correspond to setting up the BPF program and configuring the XSK cache pool, respectively.

[0029] The implemented stmmac_bpf function overrides the network device's net_device_ops operation interface ndo_bpf during system startup. static const struct net_device_ops stmmac_netdev_ops = { ...... .ndo_bpf = stmmac_bpf, / / overload ndo_bpf ...... }; Implement the BPF system call of the operating system; XDP functions are executed through this BPF system call.

[0030] The ndo_bpf interface is defined in: ; 2. stmmac_xdp_setup_pool function Function prototype: int stmmac_xdp_setup_pool(struct stmmac_priv priv, struct xsk_buff_pool pool, u16 queue) See Table 2 for parameters / return values: Table 2 Parameters / Return Values ​​of the stmmac_xdp_setup_pool Function

[0031] Program logic: The process of configuring a cache pool is as follows: Figure 4 As shown, when configuring the XSK cache pool, it is necessary to check whether the passed-in XSK cache pool pointer is null.

[0032] If not empty, it indicates that a DMA mapping between the network card device and the UEMU shared cache needs to be added, and a zero-copy processing procedure needs to be executed. Specifically: obtain the UEMU shared memory in the cache pool; search for the DMA mapping. If the DMA mapping is found, initialize the DMA mapping and increment the mapping reference count. If the DMA mapping is not found, create the DMA mapping, establish the hardware and UEMU cache mapping relationship, and initialize the DMA mapping; then determine whether the DMA mapping needs to be updated. If it does not need to be updated, set the queue zero-copy flag; if it needs to be updated, execute the following steps in sequence: disable the RX queue, disable the TX queue, disable RX NAPI scheduling, disable TX NAPI scheduling, set the queue zero-copy flag, enable zero-copy soft interrupt scheduling, enable the TX queue, enable the RX queue, and wake up the network card XDP socket.

[0033] If empty, it indicates that the xsk cache pool needs to be deleted. Specifically: obtain the xsk cache pool, check if the xsk cache pool is empty, if empty, end; if not empty, further check if the xsk cache pool needs to be updated (the condition for updating is that the current device is in use and the BPF program has been set). If no update is needed, delete the hardware and umem cache mapping relationship and clear the queue zero-copy flag; if an update is needed, execute the following in sequence: disable the RX queue, disable the TX queue, disable zero-copy soft interrupt scheduling, delete the hardware and umem cache mapping relationship, clear the queue zero-copy flag, enable RX NAPI scheduling, enable TX NAPI scheduling, enable the TX queue, and enable the RX queue.

[0034] 3. stmmac_xdp_run_prog function Function prototype: struct sk_buff stmmac_xdp_run_prog(struct stmmac_priv priv,struct xdp_buff xdp) See Table 3 for parameters / return values: Table 3. Parameters / Return Values ​​of the stmmac_xdp_run_prog Function

[0035] Program logic: The execution flow of the network card driver BPF XDP program is as follows: Figure 5 As shown: The process involves calling `rcu_read_lock` to acquire the BPF program, executing the BPF program, and sending data to the device when it returns `XDP_TX`. If processing fails, it returns `STMMAC_XDP_CONSUMED`; otherwise, it returns `STMMAC_XDP_TX`. During redirection processing, if it fails, it returns `STMMAC_XDP_CONSUMED`; otherwise, it returns `STMMAC_XDP_REDIRECT`. Exception information is recorded, and `XDP_ABORTED` is returned. Finally, `rcu_read_unlock` is called.

[0036] 4. stmmac_rx_zc function Function prototype: int stmmac_rx_zc(struct stmmac_priv priv, int limit, u32queue) Parameters / return values ​​are shown in Table 4: Table 4. Parameters / Return Values ​​of the stmmac_rx_zc Function

[0037] Program logic: The `stmmac_rx_zc` function is used for zero-copy data packet reception, and the processing flow is as follows: Figure 6 As shown: When receiving data packets in a loop, the network card driver first reads the data into the xsk buffer in the receive queue via DMA. The xsk buffer is memory requested by the user-space application, and it shares memory with the kernel space through memory mapping. Simultaneously, this memory is mapped using DMA technology and hardware to ensure that received data is directly stored in the shared buffer. Specifically: It receives packets in a loop, checks if the number of packets processed exceeds a threshold. If it does, it stops receiving and uses xsk to send the data to user space or a forwarding device, sending the data to be sent to the application via a socket or forwarding it. If it does not exceed the threshold, it reads the data into the uem buffer in the receive queue using DMA. After receiving the data, it executes the BPF program and checks the execution result. If the execution result is not XDP_PASS, it redirects the data. When the execution result is XDP_PASS, it constructs an sk_buff, merges the sk_buffs, and continues to send the data to the kernel network protocol stack for processing. Finally, it returns the actual number of packets processed.

[0038] 5. stmmac_xdp_xmit_zc function Function prototype: bool stmmac_xdp_xmit_zc(struct stmmac_priv (priv, u32 queue, u32 budget) Parameters / return values ​​are shown in Table 5: Table 5. Parameters / Return Values ​​of the stmmac_xdp_xmit_zc Function

[0039] Program logic: The network card driver's zero-copy transmission process is as follows: Figure 7As shown. When the network card driver sends packets with zero copy, it retrieves the data to be sent from the xsk buffer pool of the sending queue. After converting the retrieved data into a DMA address, it puts the DMA address into the DMA descriptor of the sending queue. The DMA descriptor address can send the data packet to the network card through DMA. During the traversal, if the remaining amount to be sent is less than the threshold or there is no data to be sent, the sending stops. Specifically: retrieve the data packet sending queue, retrieve the data packet sending queue xsk buffer pool, send data packets in a loop, calculate the remaining amount of data to be sent, and end when the remaining amount of data is less than a predetermined threshold. When the remaining amount of data is greater than or equal to the predetermined threshold, retrieve the XDP descriptor from the xsk buffer pool. If the retrieval fails, the process ends. If the retrieval is successful, the following steps are executed in sequence: retrieve the DMA descriptor, retrieve the data packet physical address, DMA synchronization device, fill the sending queue with the data to be sent, enable hardware to send data packets, and return to the loop to send data packets.

[0040] 6. stmmac_open function Function prototype: int stmmac_open(struct net_device dev) Parameters / return values ​​are shown in Table 6: Table 6. Parameters / Return Values ​​of the stmmac_open Function

[0041] Program logic: Figure 8 The network interface card (NIC) hardware activation process is illustrated. Within this hardware activation process, during allocation... When allocating resources, if XDP is supported, the zero-copy NAPI flag needs to be assigned to the receive queue when allocating receive queue resources. This means that packet reception is processed through a zero-copy procedure. Specifically: The process involves obtaining the device runtime return value. If obtaining the return value fails, the process ends. If successful, the following steps are executed sequentially: initializing the driver's PHY state, allocating TX / RX resources, initializing the DMA engine, initializing the MAC core, setting the RX / TX queue loop length, starting the DMA channel, requesting the IRQ line, enabling all data queue operations on the network card, enabling NAPI scheduling, and ending.

[0042] When initializing the RX / TX descriptor ring, if zero-copy is supported, the DMA address of the receive queue is configured in zero-copy mode. In this scenario, the DMA address points to the UMEM shared memory allocated by the user space when the socket is bound. See the init_dma_desc_rings function for details.

[0043] 7. The `init_dma_desc_rings` function Function prototype: int init_dma_desc_rings(struct net_device dev, gfp_t flags) Parameters / return values ​​are shown in Table 7: Table 7 Parameters / Return Values ​​of the init_dma_desc_rings Function

[0044] Program logic: Figure 9 The DMA descriptor ring initialization process is described. DMA descriptor ring initialization includes the initialization of the RX descriptor ring and the initialization of the TX descriptor ring. After initialization, the RX and TX descriptors need to be cleared. The purpose of clearing the descriptors is to empty the descriptor addresses, preparing for setting descriptor addresses for subsequent message transmission and reception.

[0045] When initializing the RX descriptor ring, it is necessary to consider whether the XDP address family is supported and whether the zero-copy option is set. Only when both of these conditions are met will the XSK cache pool be established on the network device. The detailed processing procedure is as follows: Figure 10 As shown. When retrieving the cache for network interface card (NIC) packets, if the XSK cache pool is not empty, it means that UMEM shared memory is used as the packet cache address; if it is empty, kernel memory needs to be allocated as the packet cache address. Specifically: obtain the number of RX queues, initialize the RX descriptor ring in a loop, obtain the XSK cache pool, and check if the XSK cache pool is empty. When the XSK cache pool is empty, register the XSK type cache pool model and allocate the NIC's zero-copy receive buffer; when the XSK cache pool is not empty, register the PAGE type cache pool model and allocate the NIC's memory page buffer.

[0046] III. Implementation Plan Design The functions implemented by the network component involve the following processes: hardware initialization process, XDP socket configuration process, zero-copy message reception process, and message transmission process.

[0047] 1. Hardware Initialization Process Figure 11 The network interface card (NIC) hardware initialization process is illustrated. The current hardware initialization process already implements the basic functions of the NIC, including setting the MAC address, setting the MTU, and adding NAPI polling point processing functions. This invention primarily supports the NIC's XDP packet transmission and reception capabilities on top of these existing functions. Therefore, a zero-copy processing procedure needs to be added when adding the NAPI polling point processing functions.

[0048] 2. XDP Socket Configuration Process The application configuration process for XDP sockets is as follows: Figure 12 As shown, after the application creates a socket (using the PF_XDP address family, SOCK_RAW format), it sequentially calls the socket option settings, registers UMEM memory, and sets the FQ, CQ, RX, and TX queue options respectively. The application will obtain the socket options, perform queue memory mapping, and when the socket and interface are bound, the xsk unit executes the BPF instruction, calls the network card driver unit to configure the XSK cache pool, establishes the DMA mapping relationship between the device and the UMEM shared cache, and releases the socket after configuration is complete.

[0049] 3. Zero-copy message reception process Figure 13 The diagram illustrates the zero-copy message reception process of the network card driver. The zero-copy message reception process is similar to the message reception process, except that it uses zero-copy message reception. In the message reception process, messages read from the hardware via DMA are stored in the kernel cache of the receive queue. When transferring data from the kernel cache to user space, a zero-copy operation is required. In the zero-copy reception process, messages read from the hardware via DMA are stored in UMEM shared memory. The kernel and application programs can access shared memory simultaneously, reducing the performance overhead of data copying and improving message transmission and reception efficiency. Specifically: the network interface card (NIC) device initiates an interrupt request to the NIC driver unit; the NIC driver unit processes the received interrupt request through the NAPI polling message receiving and processing interface; the NIC device reads the message from the NIC buffer; the DMA unit writes the message to the kernel buffer; when transferring data from the kernel buffer to user space, a zero-copy operation is performed; the BPF_XDP message filtering unit executes the message filtering XDP program; the NIC driver unit redirects the message to the XSK unit; the XSK unit copies the message from the XDP socket to user space; and the NIC driver unit forwards the message to the NIC device through the DMA interface.

[0050] 4. Message Sending Process Figure 14 The message sending process is described. The application copies the message to the kernel space cache through the XSK unit. The network card driver unit processes the received message through the NAPI polling message sending and processing interface, and then synchronizes the data packet cache to the network card device through the DMA interface.

[0051] Tests on FT2000 / 4 and RK3588 show that, using the method of this invention, communication speed is increased by more than 50% and protocol stack latency is reduced by more than 30% compared to standard UDP network communication.

[0052] As described above, this invention utilizes the high-performance, programmable network packet processing framework provided by the Linux Kernel, specifically an eBPF Hook within the Linux Kernel Network Subsystem, to dynamically mount eBPF program logic. This enables the kernel to perform targeted high-speed processing on data packets when they reach the L2 (network card driver layer), without having to conventionally enter the TCP / IP protocol stack, thereby improving kernel network communication efficiency.

[0053] Please note that the technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. The above embodiments only illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be pointed out that those skilled in the art can make several modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. An optimized kernel network, characterized in that, This kernel network includes: the Fast Data Path Component (XDP) located at the data link layer and Berkeley Packet Filter Maps (BPF Maps); among which... BPF Maps are used for key-value pair storage and serve as a communication medium between the application and XDP; the application predefines rules in BPF Maps. When a network interface card (NIC) device receives network data packets, XDP parses the received packets and filters them according to rules, or encapsulates or decapsulates the received packets, modifies fields, and forwards the packets; specifically including: XDP sends message packets directly to the application through its XSK unit; XDP requests a socket buffer (SKB), stores the packet data in the SKB, and then sends it to the kernel network protocol stack for processing. XDP redirects message packets to other CPUs or network interface cards. XDP matches message packets against rules in BPF Maps to filter message packets, and discards message packets that are invalid; XDP stores packet statistics in BPF Maps, and applications can access packet statistics by accessing BPF Maps.

2. The kernel network as described in claim 1, characterized in that, XDP includes: a network interface card driver unit, a BPF-XDP packet filtering unit, a DMA unit, and an XSK unit; among which: The network interface card (NIC) driver unit includes multiple link layer interfaces for NIC device hardware initialization, packet and data packet reception, and packet and data packet transmission. The DMA unit is used to provide data transfer between the network interface card (NIC) device and the memory, as well as between memory devices; The XSK unit is used to establish a channel between the application and the kernel, and to transfer the packet data of the network card device to the application by using memory mapping and fast data channel technology. The BPF-XDP packet filtering unit is used to filter the packet data received by the network card driver unit and perform redirection and kernel protocol stack operations based on the returned results. The network interface card (NIC) driver unit has multiple link layer interfaces, including: a first interface for executing BPF commands, a second interface for configuring the XSK buffer pool, a third interface for NIC driver BPF XDP, a fourth interface for zero-copy receiving of packet data, a fifth interface for NIC driver zero-copy sending of packet data, a sixth interface for NIC hardware enabling, and a seventh interface for initializing the DMA description ring.

3. The kernel network as described in claim 2, characterized in that, The first interface for executing BPF commands implements its functionality by determining whether to set up a BPF program or build an xsk cache pool by judging the type of the BPF command.

4. The kernel network as described in claim 2, characterized in that, The second interface for configuring the XSK cache pool implements its functionality as follows: When configuring the XSK cache pool, check if the passed-in XSK cache pool pointer is null; If not empty, then: retrieve the shared memory of the cache pool umem; The process involves searching for a DMA mapping. If a DMA mapping is found, it is initialized and the mapping reference count is incremented. If no DMA mapping is found, it is created, the hardware and UEMB cache mapping relationship is established, and the DMA mapping is initialized. Next, it is determined whether the DMA mapping needs to be updated. If it does not need to be updated, the queue zero-copy flag is set. If it needs to be updated, the following steps are executed in sequence: disable the RX queue, disable the TX queue, disable RX NAPI scheduling, disable TX NAPI scheduling, set the queue zero-copy flag, enable zero-copy software interrupt scheduling, enable the TX queue, enable the RX queue, and wake up the network card XDP socket. If empty, then: obtain the xsk buffer pool, check if the xsk buffer pool is empty, if empty, end; if not empty, further check if the xsk buffer pool needs to be updated, if no update is needed, delete the hardware and umem cache mapping relationship, and clear the queue zero-copy flag; if an update is needed, then sequentially execute de-enable RX queue, de-enable TX queue, de-enable zero-copy soft interrupt scheduling, delete the hardware and umem cache mapping relationship, clear the queue zero-copy flag, enable RX NAPI scheduling, enable TX NAPI scheduling, enable TX queue, and enable RX queue.

5. The kernel network as described in claim 2, characterized in that, The third interface used for the BPF XDP network card driver implements its interface functionality in the following way: Call rcu_read_lock to obtain the BPF program, execute the BPF program, and when the BPF program returns XDP_TX, send the packet to the network card device. If the sending fails, return STMMAC_XDP_CONSUMED, otherwise return STMMAC_XDP_TX. When performing redirection processing, if the redirection fails, return STMMAC_XDP_CONSUMED, otherwise return STMMAC_XDP_REDIRECT.

6. The kernel network as described in claim 2, characterized in that, The fourth interface for zero-copy message data reception implements its interface functionality in the following manner: The system continuously receives message data packets, checks whether the number of message data packets processed exceeds a threshold, and stops receiving if the threshold is exceeded. It then uses xsk to send message data packets to user space or forwarding devices, and sends the message data packets that need to be sent to the application or forwards them through sockets. If the threshold is not exceeded, the message data packet is read into the receive queue umem buffer using DMA. After receiving the message data packet, the BPF program is executed, and the execution result is judged. If the execution result is not XDP_PASS, the message data packet is redirected. When the execution result is XDP_PASS, an sk_buff is constructed, multiple constructed sk_buffs are merged, and the message data packet is sent to the kernel network protocol stack for processing. Finally, the number of message data packets actually processed is returned.

7. The kernel network as described in claim 2, characterized in that, The fifth interface, used for zero-copy transmission of message data packets by the network card driver, implements its interface function in the following way: The process retrieves the packet sending queue and the packet sending queue xsk buffer pool. It then sends packet data in a loop, calculating the remaining number of packet data to be sent. The process ends when the remaining number of packet data is less than a predetermined threshold. If the remaining number of packet data is greater than or equal to the predetermined threshold, the process retrieves the XDP descriptor from the xsk buffer pool. If the XDP descriptor retrieval fails, the process ends. If the XDP descriptor retrieval is successful, the process executes the following steps in sequence: retrieve DMA descriptor, retrieve packet data physical address, DMA synchronization device, fill the sending queue with packet data, enable hardware to send packet data, and return to the loop to send packet data.

8. An optimized kernel network implementation method, employing the kernel network described in any one of claims 1-7, characterized in that, The method includes the following steps: Step 1, hardware initialization, includes: setting the MAC address, setting the MTU, and adding the NAPI polling point processing function; among them, a zero-copy processing procedure is added when adding the NAPI polling point processing function; Step 2: The application configures the XDP socket; the xsk unit executes BPF instructions, calls the network card driver unit to configure the XSK cache pool, and establishes the DMA mapping relationship between the device and the UMEM shared cache; Step 3, zero-copy reception of network card driver messages; in the zero-copy reception process, the messages read from the hardware through the DMA mechanism are stored in the UMEM shared memory; Step 4: The application copies the packets to the kernel space cache through the XSK unit. The network card driver unit processes the received packets through the NAPI polling packet sending and processing interface, and then caches the data packets and synchronizes them to the network card device through the DMA unit.

9. The method as described in claim 8, characterized in that, Step 2 specifically includes: after the application creates the socket, it sequentially sets multiple socket options to register UMEM memory, set FQ, CQ, RX, and TX queues; the application obtains the socket options, performs queue memory mapping, and binds the socket to the interface.

10. The method as described in claim 8, characterized in that, Step 3 specifically includes: the network interface card (NIC) device initiating an interrupt request to the NIC driver unit; the NIC driver unit processing the received interrupt request through the NAPI polling message receiving and processing interface; the NIC device reading messages from the NIC buffer; the DMA unit writing messages to the kernel buffer; performing zero-copy operations when transferring data from the kernel buffer to user space; the BPF_XDP message filtering unit executing the message filtering XDP program; the NIC driver unit redirecting message packets to the XSK unit; the XSK unit copying message packets to user space through the XDP socket; and the NIC driver unit forwarding messages to the NIC device through the DMA interface.

Images