Kernel bypass-based non-sharing architecture key value cache acceleration method and system

Abstract

The invention provides a kernel bypass-based non-sharing architecture key value cache acceleration method and system, and the method comprises the steps: splitting a complete key value cache processing logic into a plurality of eBPF subprograms, compiling the plurality of eBPF subprograms into bytecode files, loading the bytecode files to a kernel, and mounting the bytecode files to an XDP hook point of a specified network interface; eBPF mapping is created and initialized; the method comprises the following steps: receiving a data packet at a network card driving layer through an XDP hook point, after screening a target data packet conforming to a preset protocol type and a port, analyzing the target data packet to extract a request command type and a key, calculating a hash value of the key, and temporarily storing the request command type and the hash value in a head reserved field of the target data packet; redirecting the target data packet to the target CPU core in combination with eBPF mapping, the request command type and the hash value; and the target CPU core executes data operation on the target data packet to generate a response message, and sends or forwards the response message from the receiving network card to the target network card. According to the method, high-performance cache processing in the kernel is realized.

Description

Technical Field

[0001] This invention relates to the field of memory key-value caching technology, and in particular to a method and system for accelerating key-value caching based on kernel bypass and a shared-nothing architecture. Background Technology

[0002] Key-value caching systems are core components for improving application data access performance and are widely used in databases, content delivery networks, and large-scale web services. Traditional key-value caching systems generally rely on socket interfaces provided by the operating system kernel for network communication. While this simplifies the development process, it introduces significant system call overhead and burdens the kernel network protocol stack. Although existing technologies exist that combine multiple requests to distribute input / output overhead, they cannot fundamentally overcome the performance bottleneck caused by kernel-mode packet processing. Furthermore, this approach is subject to many limitations in practical applications, as not all client requests can be combined.

[0003] On the other hand, existing key-value stores mostly employ a multi-threaded concurrent access model, using mutexes, optimistic locks, or lock-free data structures to protect shared data. However, under this model, high-concurrency write operations can easily trigger cache line synchronization between CPU cores, leading to performance degradation. Especially in systems based on eBPF technology, due to its limited programming model, it only supports basic spinlocks and cannot cross-function calls, making it difficult to efficiently implement traditional concurrency control primitives. This results in a significant increase in CPU load under high-concurrency scenarios, limiting the overall system performance.

[0004] Furthermore, although existing research has attempted to improve system scalability by implementing a shared-nothing architecture using programmable network interface cards (NICs) or specific hardware, such solutions often rely on dedicated hardware, resulting in shortcomings in versatility and deployment flexibility. Meanwhile, software-based traffic distribution mechanisms (such as RPS and RFS) currently cannot match the performance of hardware-level RSS technology and cannot fully meet the needs of high-performance key-value caching systems for packet processing and load balancing across CPU cores. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention proposes a kernel-bypass-based shared-nothing architecture key-value cache acceleration method and system. This method relies on eBPF technology to achieve high-performance cache processing in the kernel.

[0006] This invention provides a method for accelerating key-value caching in a shared-nothing architecture based on kernel bypass, comprising:

[0007] The complete key-value cache processing logic is split into multiple eBPF subroutines. After compiling these multiple eBPF subroutines into bytecode files, they are loaded into the kernel and attached to the XDP hook point of the specified network interface.

[0008] Create and initialize eBPF mappings;

[0009] The XDP hook point receives data packets at the network card driver layer, filters target data packets that match the preset protocol type and port, parses the target data packets to extract the request command type and key, calculates the hash value of the key, and temporarily stores the request command type and the hash value in the reserved field of the header of the target data packet.

[0010] Based on the eBPF mapping, the request command type, and the hash value, the target data packet is redirected to the target CPU core;

[0011] The target CPU core performs data operations on the target data packet to generate a response message, and sends the response message from the receiving network card or forwards the response message to the target network card.

[0012] In one embodiment of the present invention, the eBPF mapping includes a program array mapping, a CPU redirection mapping, and a per-CPU hash mapping;

[0013] The program array mapping is used to store the indexes and file descriptors of each subroutine. When a tail call jumps, the target subroutine is located by querying this mapping.

[0014] The CPU redirection mapping is used to obtain the target CPU index by dividing the number of CPUs by the hash value, and forward the target data packet to the CPU queue corresponding to the index through a function for redirecting data packets. The queue length and the processor ID are configured for each CPU entry.

[0015] The per-CPU hash map is used to allocate an independent data storage partition for each CPU core. The CPU core performs operations on the per-CPU hash map in FIFO order and does not require a locking mechanism for synchronization.

[0016] In one embodiment of the present invention, the process of compiling the plurality of eBPF subroutines into bytecode files and loading them into the kernel includes:

[0017] Using the Clang compiler, compile the multiple eBPF subroutines into ELF format bytecode files;

[0018] The bytecode file is loaded into the kernel via a system call used to load the eBPF program. After verification by the eBPF verifier, the main eBPF program is mounted to the network interface via a function that mounts the XDP program. The flag of the function that mounts the XDP program is set to driver mode.

[0019] In one embodiment of the present invention, the hash value of the key is calculated by the jhash function provided by the kernel or a custom hash function, and the reserved field is a reserved field in the UDP header, including a 2-byte field for storing the request command type and a 4-byte field for storing the hash value.

[0020] In one embodiment of the present invention, when the request command type is a read request, the current CPU core directly executes the query operation through the local per-CPU data mapping;

[0021] When the request command type is a write request, the hash value is read from the reserved field, and the target data packet is redirected to the target CPU core through the CPU redirection mapping.

[0022] In one embodiment of the present invention, the memory of the per-CPU hash map is managed by the kernel Slab allocator, and the metadata of the key-value pairs is stored in a 4-byte key-value combination structure.

[0023] In one embodiment of the present invention, the preset protocol type is IPv4 and UDP, and the preset port is the default port of Memcached;

[0024] If the data packet does not conform to the preset protocol type or port, the data packet will be handed over to the kernel network stack for processing.

[0025] In one embodiment of the present invention, the target CPU core performs data operations on the target data packet to generate a response message, comprising:

[0026] The target CPU core retrieves the target data packet from the queue of the CPU redirection mapping, operates the local per-CPU data mapping based on the temporarily stored request command type and hash value, performs data insertion, update or deletion operations, and generates the response message.

[0027] In one embodiment of the present invention, sending or forwarding the response message from the receiving network card to the designated network card includes:

[0028] When the response message does not need to be forwarded, the return value of the XDP program is set to XDP_TX, and the network card driver sends the response message directly from the receiving network card.

[0029] When the response message needs to be forwarded, the target network interface is located by querying the forwarding mapping, and the response message is forwarded to the target network interface.

[0030] In another aspect, the present invention provides a key-value cache acceleration system based on kernel bypass and a shared-nothing architecture, comprising a user-mode preparation module and a kernel-mode processing module, wherein the user-mode preparation module and the kernel-mode processing module are communicatively connected, wherein:

[0031] The user-mode preparation module includes:

[0032] The program compilation and loading unit is used to split the complete key-value cache processing logic into multiple eBPF subroutines, compile the multiple eBPF subroutines into bytecode files, load them into the kernel, and attach them to the XDP hook point of the specified network interface.

[0033] The mapping management unit is used to create and initialize eBPF mappings;

[0034] The kernel-mode processing module includes:

[0035] The message processing unit is used to receive data packets at the network card driver layer through the XDP hook point, filter target data packets that conform to the preset protocol type and port, parse the target data packets to extract the request command type and key, calculate the hash value of the key, and temporarily store the request command type and the hash value in the reserved field of the header of the target data packet.

[0036] The command distribution unit is used to redirect the target data packet to the target CPU core by combining the eBPF mapping, the request command type, and the hash value.

[0037] A response generation unit is used by the target CPU core to perform data operations on the target data packet and generate a response message.

[0038] A sending control unit is used to send the response message from the receiving network card or forward the response message to the target network card.

[0039] As can be seen from the above solutions, the advantages of the present invention are:

[0040] This invention discloses a kernel-bypass-based shared-nothing architecture key-value caching acceleration method. This method involves splitting the complete key-value caching processing logic into multiple eBPF subroutines, compiling these subroutines into bytecode files using eBPF mapping, loading them into the kernel, and attaching them to an XDP hook point on a specified network interface. Through the XDP hook point, data packets are received at the network interface card (NIC) driver layer. After filtering target data packets that match a preset protocol type and port, the target data packets are parsed to extract the request command type and key. The hash value of the key is calculated, and the request command type and hash value are temporarily stored in a reserved field in the header of the target data packet. Using the eBPF mapping, the request command type, and the hash value, the target data packet is redirected to the target CPU core. The target CPU core performs data operations on the target data packet to generate a response message, which is then sent from the receiving NIC or forwarded to the target NIC. This method effectively overcomes the performance degradation caused by lock contention and cache consistency synchronization in traditional multi-threaded architectures, significantly improving throughput. Through kernel-level message processing and lock-free design, it greatly reduces the overhead of user-mode-kernel mode switching and protocol stack processing, improves the effective utilization of memory, does not depend on specific hardware support, can be deployed in general Linux kernel environments, and supports linear scaling to multi-core environments. Attached Figure Description

[0041] Figure 1 A schematic diagram of the overall process of a key-value cache acceleration method based on kernel bypass in a shared-nothing architecture provided by an embodiment of the present invention is shown.

[0042] Figure 2 A schematic diagram of the eBPF Map storage structure is shown;

[0043] Figure 3 A schematic diagram of the structure of a key-value cache acceleration system based on kernel bypass and shared-nothing architecture provided by an embodiment of the present invention is shown.

[0044] The attached figures are labeled as follows:

[0045] 300: Key-value caching acceleration system;

[0046] 310: User-mode preparation module;

[0047] 320: Kernel-mode processing module;

[0048] 3101: Program compilation and loading unit;

[0049] 3102: Mapping Management Unit;

[0050] 3201: Message Processing Unit;

[0051] 3202: Command Dispatch Unit;

[0052] 3203: Response generation unit;

[0053] 3204: Send control unit. Detailed Implementation

[0054] It should be noted that, in this invention, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0055] In the absence of further restrictions, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0056] This application aims to address the following technical challenges existing in the aforementioned key-value caching systems:

[0057] (1): Performance bottleneck caused by kernel network protocol stack processing of data packets. Traditional key-value storage systems generally rely on socket interfaces provided by the operating system kernel for network communication. Although this simplifies development, it leads to frequent system calls and kernel network protocol stack processing overhead. Although there are optimization methods to merge multiple requests to distribute input and output overhead, it still cannot fundamentally overcome the performance loss of kernel processing of data packets. Moreover, this solution is limited by the actual application scenario, and not all client requests are suitable for merging. In particular, since the eBPF validator limits the number of instructions per eBPF program to 1 million, it is not feasible to directly place the complete key-value cache processing logic in a single agent program. It is necessary to explore the program loading and execution mechanism under the condition of limited instruction number. In addition, eBPF itself cannot generate new data packets independently. It is necessary to modify and return data packets with the help of specific methods, while ensuring transparency to user space programs.

[0058] (2): Performance degradation and scalability limitations caused by traditional locking mechanisms in multi-core high-concurrency environments. Traditional multi-threaded models typically rely on mutexes, optimistic locks, or lock-free data structures to control concurrent access to shared data. However, in high-concurrency write scenarios, this can easily lead to cache line synchronization between CPU cores, resulting in performance degradation. This problem is particularly prominent in the context of eBPF technology: eBPF only supports the most basic spin lock. In high-concurrency scenarios, spin locks can easily lead to increased CPU load, making it difficult to achieve high-performance data lookup and processing.

[0059] (3): The existing hardware solutions suffer from poor versatility and scalability, while the software solutions suffer from insufficient performance. Although shared-nothing architecture designs (such as those based on programmable network cards) have improved system scalability by avoiding inter-core communication, these solutions heavily rely on specific hardware and have poor flexibility and scalability in heterogeneous environments. Furthermore, software-based traffic distribution mechanisms such as Receive Packet Forwarding (RPS) and Receive Stream Forwarding (RFS) are currently insufficient to replace hardware-based RSS (Receiver Scaling) technology. Modern network cards typically use hardware-bound hash algorithms (such as Toeplitz) to distribute traffic across different receive queues, making it difficult for developers to customize distribution logic based on application layer information. In scenarios lacking RSS support or where hardware and application deployments are incompatible, packets may be routed entirely to a single interrupt request (IRQ), creating a processing bottleneck. Debugging and adapting to such issues is often time-consuming and inefficient.

[0060] To address this, embodiments of the present invention provide a method for accelerating key-value caching in a shared-nothing architecture based on kernel bypass.

[0061] Specifically, see Figure 1 As shown, Figure 1 The diagram illustrates the overall flow of a key-value cache acceleration method based on kernel bypass in a shared-nothing architecture according to an embodiment of the present invention.

[0062] A kernel-bypass-based method for accelerating key-value caching in a shared-nothing architecture includes the following steps:

[0063] Step S1: Divide the complete key-value cache processing logic into multiple eBPF subroutines, compile the multiple eBPF subroutines into bytecode files, load them into the kernel, and attach them to the XDP hook point of the specified network interface.

[0064] In this embodiment, the complete key-value caching processing logic, such as protocol parsing, command execution, and response generation, is decomposed into multiple eBPF subroutines. These multiple eBPF subroutines are then chained together using tail calls and eBPF mapping jumps to form an eBPF program chain.

[0065] In one embodiment, a version of the Clang compiler is used, with the target bpf as a compilation parameter, to compile the plurality of eBPF subroutines into ELF format bytecode files.

[0066] The bytecode file is loaded into the kernel via the system call bpf_prog_load(), which is used to load the eBPF program. After the eBPF verifier verifies the file, the main eBPF program is mounted to the network interface via the function bpf_set_link_xdp_fd(), which is used to mount the XDP program. The flag of the function that mounts the XDP program is set to the driver mode XDP_FLAGS_DRV_MODE to achieve the highest performance.

[0067] Step S2: Create and initialize eBPF mappings.

[0068] See Figure 2 As shown, Figure 2 A schematic diagram of the eBPF Map storage structure is shown. The eBPF Map includes the program array map (BPF_MAP_TYPE_PROG_ARRAY), the CPU redirection map (BPF_MAP_TYPE_CPUMAP), and the per-CPU hash map (BPF_MAP_TYPE_PERCPU_HASH).

[0069] The program array map BPF_MAP_TYPE_PROG_ARRAY is used to store the indexes and file descriptors of each eBPF subroutine. During a tail call jump, the target subroutine is located by querying this map. The PROG_ARRAY Map is initialized by writing the file descriptors (fd) of each eBPF subroutine to the corresponding index positions for lookup during tail calls.

[0070] The CPU redirection map BPF_MAP_TYPE_CPUMAP is used to obtain the target CPU index by dividing the hash value by the number of CPUs. A queue length and an optional eBPF program ID running on the target CPU are configured for each CPU entry. The target data packet is forwarded to the CPU queue corresponding to the index using the function bpf_redirect_map(), which redirects the data packet to the corresponding CPU entry in the CPUMAP by dividing the hash value of the data packet key by the number of CPUs, thus implementing request key distribution. The CPUMAP is initialized based on the number of CPU cores (N) in the system, and a queue length and an optional subsequent processor ID are configured for each CPU entry.

[0071] The per-CPU hash map (BPF_MAP_TYPE_PERCPU_HASH) is based on a shared-nothing data storage architecture. It allocates an independent data storage partition for each CPU core to store key-value pairs. No communication or synchronization is required between CPU cores. Operations on the per-CPU hash map are executed in FIFO order on each CPU core, without the need for locking mechanisms for synchronization. In this embodiment, a dedicated per-CPU hash map is created for each CPU core, ensuring that all operations on the same key are always directed to the same CPU core. This core then operates on its local per-CPU map, thereby achieving completely lock-free concurrent access.

[0072] In one embodiment, the memory for the per-CPU hash map is managed by the kernel Slab allocator for efficient memory management. Simultaneously, a highly compact data structure design is employed, such as reusing hash slots to reduce pointer overhead, selecting shorter data types (e.g., 4-byte key-value combinations), and avoiding expensive operations like compare-and-swap (CAS), significantly reducing the memory footprint of metadata, improving memory access efficiency and cache locality, thereby enhancing overall system performance and resource utilization.

[0073] In this embodiment, the complete cache processing logic is split into multiple eBPF programs. Inter-program jumps and state transfers are performed via tail calls and eBPF Maps, forming a continuous processing chain. User-space code is responsible for loading the compiled eBPF programs into the kernel network stack XDP hook point. This design supports all commonly used Memcached protocol commands (such as GET, SET, ADD, DELETE), ensuring transparent migration of existing applications without code modification. It achieves complete kernel execution of complex processing logic within the eBPF instruction limit, avoiding the overhead of forwarding to user space while maintaining compatibility with the standard Memcached protocol.

[0074] Step S3: Receive data packets at the network card driver layer through the XDP hook point, filter target data packets that match the preset protocol type and port, parse the target data packets to extract the request command type and key, calculate the hash value of the key, and temporarily store the request command type and the hash value in the reserved field of the header of the target data packet.

[0075] In one embodiment, data packets are received at the network interface card (NIC) driver layer via the XDP hook point. The XDP program is immediately invoked to filter target data packets that match a preset protocol type and port. Then, the target data packets are parsed to extract the request command type and key, the hash value of the key is calculated, and the request command type and the hash value are temporarily stored in a reserved field in the header of the target data packet. Based on the request command type, the corresponding command processing subroutine is entered via a tail call.

[0076] The preset protocol types are IPv4 and UDP, and the preset port is the default port for Memcached. If a data packet does not conform to the preset protocol type or port, the packet is handed over to the kernel network stack for processing.

[0077] Parse the Memcached protocol header to extract the request command type and key. The hash value of the key is calculated using either the kernel-provided jhash2 function or a custom-implemented lightweight hash function, ensuring high efficiency and a low collision rate.

[0078] In one embodiment, to address the issue of state loss caused by data packets potentially being forwarded to different CPU cores, the reserved field is a reserved field in the UDP header, including a 2-byte field for storing the request command type and a 4-byte field for storing the hash value. This ensures that even after cross-core forwarding occurs, the target CPU can still obtain the necessary request context information, avoiding redundant hash calculations and achieving lossless and efficient transmission of the request context during cross-core forwarding, reducing redundant calculations and further lowering processing latency.

[0079] Step S4: Combining the eBPF mapping, the request command type, and the hash value, redirect the target data packet to the target CPU core.

[0080] In this embodiment, the CPUMAP mechanism provided by the Linux kernel is used to redirect received data packets to a specific remote target CPU core for processing based on the hash value of their keys. This process fully utilizes the remote XDP program execution capability supported since Linux 5.9. By allocating an independent data partition for each CPU core and combining it with pre-calculated hash results, it is ensured that operations on the same key are always directed to the same CPU core. This achieves a true Shared-Nothing architecture, completely avoiding the performance loss and cache coherency overhead caused by synchronization primitives such as mutexes and spinlocks between multiple cores, giving the system excellent horizontal scalability.

[0081] In one embodiment, read requests (such as GET) and write requests (such as SET, ADD, DELETE) are handled differently. When the request command type is a read request, the current CPU core directly calls the `bpf_map_lookup_percpu_elem()` function to execute the query operation directly through the local per-CPU data mapping. When the request command type is a write request, it is redirected to the target CPU core. Specifically, the hash value is read from the reserved field, modulo the total number of CPUs to obtain the target CPU index, and the `bpf_redirect_map()` function is called to redirect the target data packet to the target CPU core through the CPU redirection mapping. In this embodiment, read and write requests are separated. Since each CPU has exclusive access to its own data area, all operations are executed in FIFO order, naturally avoiding data contention and eliminating the need for any locking mechanisms. This achieves completely lock-free data access, greatly improving throughput in high-concurrency scenarios and ensuring strong ordering of operations.

[0082] Step S5: The target CPU core performs data operations on the target data packet to generate a response message, and sends the response message from the receiving network card or forwards the response message to the target network card.

[0083] In one embodiment, the target CPU core retrieves the target data packet from the queue of the CPU redirection mapping, reads the request command type and hash value from the temporary storage field of the packet header, operates the local per-CPU data mapping based on the temporary request command type and hash value, performs data insertion, update or deletion operations, and generates the response packet.

[0084] When the response message does not need to be forwarded, after writing the Value into the return packet, the return value of the XDP program is set to XDP_TX. The network card driver then sends the response message directly from the receiving network card back along the original path, without having to push the data packet to the upper-layer network protocol stack, thereby achieving high-speed response within the kernel.

[0085] When the response message needs to be forwarded, the target network interface card is located by querying the forwarding map DEVMAP, and the response message is forwarded to the target network interface card.

[0086] This embodiment employs a kernel-based direct response and flexible forwarding mechanism based on XDP_TX and DEVMAP. After parsing and processing legitimate commands at the XDP layer, the response packet is directly returned from the receiving network card via the XDP_TX action, or the data packet is forwarded to another designated network card using DEVMAP. The entire process eliminates the need to push data packets to the upper-layer network stack or user space, achieving true kernel bypass processing. This mechanism is designed for stateless sessions, eliminating the need to maintain TCP connection state and avoiding protocol conversion overhead. It completely eliminates context switching overhead and data copying overhead between user mode and kernel mode, significantly reducing request processing latency while providing flexible data packet output control capabilities.

[0087] Compared with existing technologies, the kernel bypass-based shared-nothing key-value caching acceleration method provided in this embodiment exhibits excellent overall performance and stability in most practical application environments, and is particularly suitable for large-scale key-value caching scenarios with strict requirements for throughput and latency. Specifically, it has the following significant beneficial effects:

[0088] (1) Significantly improved throughput: Under standard YCSB test load, this system can achieve a throughput of approximately 226k requests per second in an 8-core environment, which is 1.8 times higher than that of the traditional Memcached system. The system performance shows a good expansion trend with the increase of the number of CPU cores, effectively overcoming the performance degradation problem caused by lock contention and cache consistency synchronization in the traditional multi-threaded architecture.

[0089] (2) Significantly optimized latency performance: In a typical read-intensive scenario (95% read requests), the median latency of the system in this invention is 86.4 μs, which is significantly lower than Memcached's 344.7 μs and BMC's 107 μs. Through kernel-level packet processing and lock-free design, the system greatly reduces the overhead of user-mode-kernel mode switching and protocol stack processing.

[0090] (3) High memory utilization efficiency: By adopting a compact metadata structure and a shared-nothing memory model, the system uses less memory than traditional key-value systems when storing the same number of key-value pairs, avoiding the extra overhead caused by redundant pointers and lock-related metadata, and improving the effective utilization of memory.

[0091] (4) It has good scalability and cross-platform versatility: It is purely software-based, does not depend on specific hardware support, and can be deployed in a general Linux kernel environment. It uses CPUMAP and hash bootstrapping mechanism to distribute requests via key presses and supports linear scaling to multi-core environments.

[0092] (5) Support lossless synchronization of request context across cores: By reusing the reserved fields in the message header to temporarily store the command type and hash value, the state of the request is maintained during cross-CPU processing, avoiding repeated calculations and further improving processing efficiency.

[0093] This embodiment corresponds to the device embodiment described above, such as... Figure 3 As shown, Figure 3 Show

[0094] A schematic diagram of a key-value cache acceleration system based on kernel bypass based on a shared-nothing architecture provided by an embodiment of the present invention is shown. This system implementation can be implemented in conjunction with the above-described method implementation. The relevant technical details mentioned in the above method implementation are still valid in this system implementation, and will not be repeated here to avoid repetition.

[0095] A kernel-bypass-based shared-nothing key-value caching acceleration system 300 includes a user-mode preparation module 310 and a kernel-mode processing module 320. The user-mode preparation module 310 is the loader and controller of the eBPF program chain, typically a server running a user-mode management program. The kernel-mode processing module is the actual processor of key-value requests and runs within the Linux kernel.

[0096] The user-mode preparation module 310 includes:

[0097] The program compilation and loading unit 3101 is used to split the complete key-value cache processing logic into multiple eBPF subroutines, compile the multiple eBPF subroutines into bytecode files, load them into the kernel, and attach them to the XDP hook point of the specified network interface.

[0098] The mapping management unit 3102 is used to create and initialize eBPF mappings.

[0099] The kernel-mode processing module 320 includes:

[0100] The message processing unit 3201 is used to receive data packets at the network card driver layer through the XDP hook point, filter target data packets that conform to the preset protocol type and port, parse the target data packets to extract the request command type and key, calculate the hash value of the key, and temporarily store the request command type and the hash value in the reserved field of the header of the target data packet.

[0101] Command distribution unit 3202 is used to redirect the target data packet to the target CPU core by combining the eBPF mapping, the request command type and hash value.

[0102] The response generation unit 3203 is used by the target CPU core to perform data operations on the target data packet to generate a response message.

[0103] The sending control unit 3204 is used to send the response message from the receiving network card or forward the response message to the target network card.

[0104] This system embodiment can be implemented in conjunction with the implementation methods described above. The relevant technical details mentioned in the implementation methods of the above embodiments remain valid in the implementation methods of this system embodiment, and will not be repeated here to avoid repetition. It should be noted that the scope of the methods and systems in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be applied, omitted, or combined. Furthermore, features described with reference to certain examples may be combined in other examples.

[0105] This invention also provides a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the aforementioned kernel bypass-based shared-nothing architecture key-value cache acceleration method, and achieve the same technical effect.

[0106] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described kernel bypass-based shared-nothing architecture key-value cache acceleration method, and achieves the same technical effect.

[0107] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0108] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software program product is stored in a storage medium and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0109] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. A method for accelerating key-value caching in a shared-nothing architecture based on kernel bypass, characterized in that, include: The complete key-value cache processing logic is split into multiple eBPF subroutines. After compiling these multiple eBPF subroutines into bytecode files, they are loaded into the kernel and attached to the XDP hook point of the specified network interface. Create and initialize eBPF mappings; The XDP hook point receives data packets at the network card driver layer, filters target data packets that match the preset protocol type and port, parses the target data packets to extract the request command type and key, calculates the hash value of the key, and temporarily stores the request command type and the hash value in the reserved field of the header of the target data packet. Based on the eBPF mapping, the request command type, and the hash value, the target data packet is redirected to the target CPU core; The target CPU core performs data operations on the target data packet to generate a response message, and sends the response message from the receiving network card or forwards the response message to the target network card.

2. The method according to claim 1, characterized in that, The eBPF mapping includes program array mapping, CPU redirection mapping, and per-CPU hash mapping; The program array mapping is used to store the indexes and file descriptors of each subroutine. When a tail call jumps, the target subroutine is located by querying this mapping. The CPU redirection mapping is used to obtain the target CPU index by dividing the number of CPUs by the hash value, and forward the target data packet to the CPU queue corresponding to the index through a function for redirecting data packets. The queue length and the processor ID are configured for each CPU entry. The per-CPU hash map is used to allocate an independent data storage partition for each CPU core. The CPU core performs operations on the per-CPU hash map in FIFO order and does not require a locking mechanism for synchronization.

3. The method according to claim 1, characterized in that, After compiling the multiple eBPF subroutines into bytecode files, they are loaded into the kernel, including: Using the Clang compiler, compile the multiple eBPF subroutines into ELF format bytecode files; The bytecode file is loaded into the kernel via a system call used to load the eBPF program. After verification by the eBPF verifier, the main eBPF program is mounted to the network interface via a function that mounts the XDP program. The flag of the function that mounts the XDP program is set to driver mode.

4. The method according to claim 1, characterized in that, The hash value of the key is calculated using the jhash function provided by the kernel or a custom hash function. The reserved field is a reserved field in the UDP header, including a 2-byte field for storing the request command type and a 4-byte field for storing the hash value.

5. The method according to claim 2, characterized in that, in, When the request command type is a read request, the current CPU core directly executes the query operation through the local per-CPU data mapping; When the request command type is a write request, the hash value is read from the reserved field, and the target data packet is redirected to the target CPU core through the CPU redirection mapping.

6. The method according to claim 2, characterized in that, The memory for the per-CPU hash map is managed by the kernel Slab allocator, and the metadata of the key-value pairs is stored in a 4-byte key-value pair structure.

7. The method according to claim 1, characterized in that, The preset protocol types are IPv4 and UDP, and the preset port is the default port for Memcached. If the data packet does not conform to the preset protocol type or port, the data packet will be handed over to the kernel network stack for processing.

8. The method according to claim 2, characterized in that, The target CPU core performs data operations on the target data packet to generate a response message, including: The target CPU core retrieves the target data packet from the queue of the CPU redirection mapping, operates the local per-CPU data mapping based on the temporarily stored request command type and hash value, performs data insertion, update or deletion operations, and generates the response message.

9. The method according to claim 1, characterized in that, Sending or forwarding the response message from the receiving network card to the designated network card includes: When the response message does not need to be forwarded, the return value of the XDP program is set to XDP_TX, and the network card driver sends the response message directly from the receiving network card. When the response message needs to be forwarded, the target network interface is located by querying the forwarding mapping, and the response message is forwarded to the target network interface.

10. A key-value cache acceleration system based on kernel bypass and a shared-nothing architecture, characterized in that, It includes a user-mode preparation module and a kernel-mode processing module, wherein the user-mode preparation module and the kernel-mode processing module are communicatively connected, wherein: The user-mode preparation module includes: The program compilation and loading unit is used to split the complete key-value cache processing logic into multiple eBPF subroutines, compile the multiple eBPF subroutines into bytecode files, load them into the kernel, and attach them to the XDP hook point of the specified network interface. The mapping management unit is used to create and initialize eBPF mappings; The kernel-mode processing module includes: The message processing unit is used to receive data packets at the network card driver layer through the XDP hook point, filter target data packets that conform to the preset protocol type and port, parse the target data packets to extract the request command type and key, calculate the hash value of the key, and temporarily store the request command type and the hash value in the reserved field of the header of the target data packet. The command distribution unit is used to redirect the target data packet to the target CPU core by combining the eBPF mapping, the request command type, and the hash value. A response generation unit is used by the target CPU core to perform data operations on the target data packet and generate a response message. A sending control unit is used to send the response message from the receiving network card or forward the response message to the target network card.

Images