Flow table management method, device and equipment for data packet processing and storage medium

Abstract

The application relates to the computer technical field, in particular to cloud technology, and provides a flow table management method and device for data packet processing, equipment and a storage medium, a cascaded ring queue data structure is used to store and manage flow tables, and the efficiency of flow table management is improved. Specifically, for each thread requesting to allocate a flow table, flow table information is allocated based on the priority order of each level of flow table queue, since each thread exclusively uses a first level of flow table queue, the threads do not compete for flow table information, thus, a lock-free and concurrent flow table allocation mode is realized, and the management efficiency of the flow table is improved. Meanwhile, for each thread requesting to release flow table information, atomic instructions are used to store the released flow table information into a third level of flow table queue, so that the released flow table information can be redistributed, and the utilization rate of the flow table information is improved. Furthermore, compared with using a database to store and manage flow tables, the occupation of memory space is saved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a flow table management method, apparatus, device, and storage medium for packet processing. Background Technology

[0002] In a Software Defined Network (SDN) architecture, the control plane and data plane are separated through the OpenFlow protocol. This allows control plane operations to be centralized on the SDN controller, while switches (such as virtual switches and SDN switches) are only responsible for simple, high-speed data plane operations locally. During data plane operations, the switches process data packets (such as lookup, modification, and forwarding) based on flow tables.

[0003] Currently, related technologies primarily use independent databases to store flow table information to manage operations such as flow table allocation and release. However, in SDN networks, the creation and aging rate of virtual switch communication links can reach millions of records per second. This means that the database receives millions of flow table management requests per second. Therefore, to ensure the order and consistency of flow table management, related technologies mainly use a single thread or locks to control database access, but this approach reduces the efficiency of flow table management. Furthermore, the flow table information in the database often resides on a specific Non-Uniform Memory Access (NUMA) node. Thus, when multiple threads request the allocation or release of flow tables, cross-NUMA node access occurs, further reducing the efficiency of flow table management.

[0004] Therefore, achieving efficient and orderly management of flow tables has become an urgent problem to be solved when processing data packets in SDN networks. Summary of the Invention

[0005] This application provides a flow table management method for packet processing, which enables efficient and orderly management of flow tables.

[0006] On one hand, embodiments of this application provide a flow table management method for packet processing, including:

[0007] The system receives flow table management requests sent concurrently by multiple threads, wherein at least one of the multiple threads runs on a NUMA node.

[0008] For each thread, perform the following operations:

[0009] When the thread's flow table management request is a flow table allocation request, a flow table information is allocated to the thread without locking, based on the priority order of the flow table information pool at each level in the memory file system. Specifically, in each level of flow table queue, each first-level flow table queue stores flow table information available to the thread itself in its local memory; each second-level flow table queue stores flow table information available to each thread on a NUMA node in its local memory; and each third-level flow table queue stores flow table information available to each NUMA node in the total memory. The flow table information in each level of flow table queue does not overlap. The priority of the first-level flow table queue is higher than that of the second-level flow table queue, and the priority of the second-level flow table queue is higher than that of the third-level flow table queue.

[0010] When the thread's flow table management request is a flow table release request, an atomic instruction is used to store the flow table information carried by the flow table release request into the third-level flow table queue.

[0011] On the other hand, embodiments of this application provide a flow table management device for packet processing, comprising:

[0012] The request receiving module is used to receive flow table management requests sent concurrently by multiple threads, wherein at least one of the multiple threads runs on a NUMA node;

[0013] The flow table management module is used to allocate a flow table information to each thread without locking when the thread's flow table management request is a flow table allocation request, based on the priority order of the flow table queues at each level contained in the flow table information pool in the memory file system; and when the thread's flow table management request is a flow table release request, it uses atomic instructions to store the flow table information carried by the flow table release request into the third-level flow table queue.

[0014] In this system, each first-level flow table queue stores flow table information available to a thread in its local memory, each second-level flow table queue stores flow table information available to each thread on a NUMA node in its local memory, and the third-level flow table queue stores flow table information available to each NUMA node in the total memory. The flow table information in each level of the flow table queue does not overlap. The priority of the first-level flow table queue is higher than that of the second-level flow table queue, and the priority of the second-level flow table queue is higher than that of the third-level flow table queue.

[0015] Optionally, the flow table management module is specifically used for:

[0016] When the first-level flow table queue of the thread itself is not empty, allocate a flow table information for the thread from the first-level flow table queue;

[0017] When the first-level flow table queue of the thread itself is empty, a flow table information is allocated to the thread from the parent flow table queue.

[0018] Optionally, the flow table management module is specifically used for:

[0019] When the second-level flow table queue of the NUMA node where the thread is located is not empty, multiple flow table information is allocated from the second-level flow table queue and stored in the first-level flow table queue of the thread itself, and one flow table information is allocated to the thread from the first-level flow table queue.

[0020] When the second-level flow table queue of the NUMA node where the thread is located is empty, multiple flow table information is allocated from the third-level flow table queue and stored in the second-level flow table queue of the NUMA node where the thread is located. Multiple flow table information is also allocated from the second-level flow table queue and stored in the first-level flow table queue of the thread itself. Finally, one flow table information is allocated to the thread from the first-level flow table queue.

[0021] Optionally, the flow table management module is specifically used for:

[0022] Obtain the current third head pointer in the third-level flow table queue, store the flow table information at the position pointed to by the third head pointer, as well as at least one flow table information thereafter, into the second-level flow table queue of the NUMA node where the thread is located, and set the third head pointer to the position of the first flow table information in the remaining flow table information.

[0023] Optionally, the flow table management module is specifically used for:

[0024] Obtain the current second head pointer in the second-level flow table queue, store the flow table information at the position pointed to by the second head pointer, as well as at least one flow table information thereafter, into the first-level flow table queue of the thread itself, and set the second head pointer to the position of the first flow table information among the remaining flow table information.

[0025] Optionally, the flow table management module is specifically used for:

[0026] Obtain the current first head pointer in the first-level flow table queue, assign the flow table information at the position pointed to by the first head pointer to the thread, and point the first head pointer to the position of the next flow table information.

[0027] Optionally, the flow table management module is specifically used for:

[0028] Obtain the current fourth head pointer in the third-level flow table queue, store the flow table information carried by the flow table release request at the position pointed to by the fourth head pointer, and move the fourth head pointer to the next position.

[0029] Optionally, the release speed of storing the flow table information carried in the flow table release request into the third-level flow table queue is less than the allocation speed of allocating flow table information to other threads without locks.

[0030] Optionally, a data processing module is also included, which is used to process the data packets transmitted by each thread based on the flow table information of each thread. The processing operation includes one of searching, forwarding, modifying and deleting the data packets. The data packets include one of image data packets, voice data packets, text data packets and web page data packets.

[0031] On the other hand, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the steps of the flow table management method for packet processing described above.

[0032] On the other hand, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions thereon, which, when executed by an electronic device, implement the steps of the flow table management method for packet processing described above.

[0033] On the other hand, embodiments of this application provide a computer program product comprising a computer program that, when executed by an electronic device, implements the steps of the flow table management method for packet processing described above.

[0034] The beneficial effects of the embodiments of this application are as follows:

[0035] This application provides a flow table management method, apparatus, electronic device, and storage medium for packet processing, which employs a cascaded ring queue data structure to store and manage flow tables. In each level of the flow table queue, each first-level flow table queue stores flow table information available to a single thread in its local memory. This means each first-level flow table queue is exclusively used by one thread, preventing contention for flow table information with other threads. Therefore, for threads requesting flow table allocation, flow table information can be allocated concurrently from their respective first-level flow table queues without locks, improving allocation efficiency. Furthermore, when no flow table information is available in the first-level flow table queue, flow table information can be allocated sequentially from the second-level and third-level flow table queues. This cascading queue approach ensures the stability of flow table information allocation for each thread. When a thread's flow table management request is a flow table release request, an atomic instruction is used to store the flow table information carried in the release request into the third-level flow table queue. Meanwhile, for each thread requesting the release of flow table information, the released flow table information is stored in the lowest-priority third-level flow table queue. This ensures that newly released flow table information can be reallocated after other flow table information is allocated, improving the utilization rate of flow table information. Furthermore, a cascaded circular queue data structure is mapped to the memory file system to achieve pooled management of flow table information. This allows each thread to access the memory file system to allocate or release flow table information as if it were accessing local memory, improving management speed.

[0036] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1A A schematic diagram illustrating the flow table management process of the related technologies provided in the embodiments of this application;

[0039] Figure 1B This is an application scenario diagram applicable to the embodiments of this application;

[0040] Figure 1C This is another application scenario diagram applicable to the embodiments of this application;

[0041] Figure 2 A flowchart illustrating a flow table management method for data processing provided in this application embodiment;

[0042] Figure 3 A schematic diagram of the NUMA architecture provided in the embodiments of this application;

[0043] Figure 4 A schematic diagram illustrating the memory usage of flow table queues at various levels provided in this application embodiment;

[0044] Figure 5 A schematic diagram of the initial contents of the third-level flow table queue provided in an embodiment of this application;

[0045] Figure 6 A flowchart of the flow table information allocation method provided in the embodiments of this application;

[0046] Figure 7A A schematic diagram illustrating the allocation of flow table information from the first-level flow table queue, provided as an embodiment of this application.

[0047] Figure 7B A schematic diagram illustrating the changes in the head and tail pointers of the first-level flow table queue provided in this embodiment of the application;

[0048] Figure 7C A schematic diagram illustrating the allocation of flow table information from the second-level flow table queue, provided as an embodiment of this application;

[0049] Figure 7D A schematic diagram illustrating the changes in the head and tail pointers of the second-level flow table queue provided in this embodiment of the application;

[0050] Figure 7E A schematic diagram illustrating the allocation of flow table information from a third-level flow table queue, provided for an embodiment of this application;

[0051] Figure 7F A schematic diagram illustrating the changes in the head and tail pointers of the third-level flow table queue provided in this embodiment of the application;

[0052] Figure 8A A schematic diagram of the pointer before storing the released flow table information in the third-level flow table queue provided in this embodiment of the application;

[0053] Figure 8B A schematic diagram of pointers after the released flow table information is stored in the third-level flow table queue provided in this embodiment of the application;

[0054] Figure 9 A structural diagram of a flow table management device for data processing provided in an embodiment of this application;

[0055] Figure 10 A structural diagram of the data classification device provided in the embodiments of this application;

[0056] Figure 11 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this application. Obviously, the described embodiments are only some embodiments of the technical solutions of this application, and not all embodiments. Based on the embodiments recorded in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the technical solutions of this application.

[0058] Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve data computing, storage, processing, and sharing.

[0059] Cloud technology is a collective term for network technology, information technology, integration technology, management platform technology, and application technology applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0060] With the development of the Internet, real-time data streams, the diversification of connected devices, and the demand for search services, social networks, mobile commerce, and open collaboration, cloud computing has developed rapidly.

[0061] Cloud computing refers to the delivery and usage model of IT infrastructure, meaning obtaining necessary resources through the network in an on-demand and easily scalable manner. In a broader sense, cloud computing refers to the delivery and usage model of services, meaning obtaining necessary services through the network in an on-demand and easily scalable manner. These services can be IT and software related, internet-related, or other services. Cloud computing is a product of the convergence and development of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing. Unlike previous parallel and distributed computing, the emergence of cloud computing will fundamentally drive a revolutionary change in the entire internet model and enterprise management model.

[0062] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0063] Switches are used to connect network devices and enable communication across networks. They can forward data packets to designated network devices to help guide network traffic, thereby enabling various networking functions. They typically include virtual switches and physical switches. Virtual switches generally refer to network switches implemented in software, while physical switches have separate hardware.

[0064] A flow table is a table stored in a switch used to perform operations such as packet identification, lookup, forwarding, and modification, thereby controlling network traffic. Each flow table consists of multiple flow entries, and each flow entry represents a packet processing rule. When a packet enters the switch, the flow table is consulted to determine the destination port for that packet processing.

[0065] Flow table information refers to a unique identifier that marks the identity of traffic within the server. For example, it can be an ID consisting of at least one of numbers, letters, and symbols.

[0066] NUMA is a memory design architecture for multiprocessors. In this architecture, memory access time depends on the relative location between the processor and memory. Generally, memory that is relatively close to the processor is called local memory, and memory that is relatively far from the processor is called non-local memory.

[0067] Atomic instructions are used to maintain synchronization relationships among multiple CPUs when multiple CPUs solve the same problem using parallel algorithms. They are indivisible instructions in the software.

[0068] Locks are a mechanism in a multi-threaded concurrent environment that ensures that only one thread is executed at any given time.

[0069] The design concept of the embodiments of this application is summarized below.

[0070] Currently, related technologies mainly use independent databases to store flow table information in order to implement management operations such as allocation and release of flow tables. This is generally suitable for single-threaded access scenarios. However, for multi-threaded concurrent access scenarios, locks are usually used to prevent dirty data from occurring.

[0071] Taking the management of concurrent flow tables using a database as an example, such as Figure 1A As shown, thread 0 needs to allocate a flow table, so it sends a database access request to obtain flow table information. Simultaneously, thread 1 needs to release a flow table, so it sends a database access request to release flow table information (ID: 23456). Since thread 0's database access request arrives at the database first, the management thread responsible for handling the allocation and release of flow table information in the database uses a lock to ensure that it will not allocate flow table information (ID: 23456) that has not yet been released back to the flow table information pool for thread 0, thus ensuring the order and consistency of the requests. After thread 0 acquires the lock, the management thread accesses the flow table information pool that stores flow table information, selects a new flow table information (ID: 12345), and returns it to thread 0. After the flow table information allocation is completed, the management thread locks again to process thread 1's database access request. By accessing the flow table information pool, it stores the flow table information (ID: 23456) released by thread 1 into the flow table information pool, and the newly stored flow table information (ID: 23456) can be reallocated and used.

[0072] Using a database for flow table management ensures the persistence of flow table information. This guarantees the consistency and durability of flow table information during hot upgrades or crashes of virtual switches. Furthermore, the database handles single-threaded flow table information allocation or release requests, while locks handle multi-threaded requests, ensuring the order of flow table information management and preventing duplicate allocation of the same flow table information or missed recycling of flow table information.

[0073] However, using a database for flow table management also has the following problems:

[0074] First, in SDN networks, the creation and aging of virtual switch communication links can reach millions of records per second. This means that millions of database accesses are required per second for managing flow table information allocation and release. Using a single thread or locks to ensure order and consistency prevents multiple threads from concurrently allocating and releasing flow table information, resulting in low management performance that is insufficient to meet the high-speed traffic demands of virtual switches. Furthermore, to ensure the transactional and persistent nature of flow table information allocation and release, the database requires that the results be stored on disk before being returned to the virtual switch threads. However, disk read / write performance is low, further limiting the database's performance in supporting flow table information allocation and release.

[0075] Secondly, when storing flow table information, the database needs to store additional metadata or management information for each flow table to facilitate management. As the number of stored flow table entries increases, the additional memory usage also increases, thus reducing memory utilization. For example, storing each flow table entry requires an additional 8 to 24 bytes; storing 100MB of flow table information would require approximately 800MB to 2.4GB of additional memory.

[0076] Third, currently, most cloud platforms use NUMA server architecture. In this architecture, different CPUs have different performance when accessing the memory of different NUMA nodes. A CPU can only achieve maximum performance when accessing the memory of the nearest NUMA node. Therefore, to achieve maximum performance, virtual switch threads may be distributed across multiple NUMA nodes, while the flow table information pool in the database is often stored only in the memory of a specific node. This results in a thread requesting the allocation or release of flow table information across NUMA nodes, which not only reduces the performance of flow table management but also causes different threads of the virtual switch to observe different network performance results, thus affecting flow control and causing network congestion. This is unfavorable for NUMA architecture.

[0077] Fourth, the allocation and release of flow table information in the database generally does not guarantee "first-in, first-out" semantics. That is, a flow table piece of information that has just been released may be reassigned immediately, rather than waiting for other unallocated flow table pieces of information to be allocated before being reallocated. The "first-in, first-out" semantics are very important for virtual switches, smart network interface cards (NICs), etc., because "first-in, first-out" ensures the predictability of flow table information allocation. That is, a flow table piece of information that has just been released will not be reallocated immediately. This provides greater flexibility for the pipeline design of virtual switches, smart NICs, etc., and is also more conducive to maintaining high-speed pipeline operation.

[0078] To address the aforementioned issues associated with using databases for flow table management, this application provides a flow table management method for packet processing. This method, based on a cascaded circular queue data structure and a memory file system, achieves efficient and lock-free flow table management. By cascading multi-level flow table queues, awareness of the NUMA architecture is achieved. When multiple threads concurrently request the allocation or release of flow tables, the method prioritizes each thread from its own available first-level flow table queue within the flow table information pool in the memory file system, thus enabling lock-free and concurrent efficient allocation of flow table information to multiple threads. Only when no available flow table information is available in its own first-level flow table queue will it sequentially retrieve information from the higher-level flow table queue, ensuring that each thread is allocated flow table information. Furthermore, released flow table information is stored in the lowest-priority third-level flow table queue, and its position in the third-level queue is determined by maintaining pointers, thus achieving predictability of the first-in, first-out (FIFO) flow table information. Meanwhile, by storing the circular data structure of the flow table queues at all levels in the memory file system, the speed of flow table information allocation and release is improved while ensuring data persistence, and no additional information is required to occupy memory, thus improving the effective utilization of memory space.

[0079] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0080] See Figure 1B The diagram shown is a possible application scenario illustration in the embodiments of this application. The application scenario illustration includes server device 100, switch 200 (specifically, it may be switch 201, switch 202, switch 203, etc.) and terminal device 300 (specifically, it may be terminal device 301, terminal device 302, etc.).

[0081] In an SDN network, terminal devices 301 and 302 communicate. Terminal device 301 sends a data packet to switch 201 in the network. If switch 201 does not have a flow table for packet forwarding, it sends a flow table request to server device 100. Upon receiving the request, server device 100 allocates a flow table for it. Switch 201 forwards the data packet to switch 202 according to a flow table entry. If switch 202 has a flow table for packet forwarding, it forwards the data packet to terminal device 302 according to a flow table entry. When communication between terminal devices 301 and 302 ends, server device 100 reclaims the flow tables released by switches 201 and 202.

[0082] In another application scenario, different terminal devices can share a single switch, such as... Figure 1C As shown, in an SDN network, terminal device 301 and terminal device 302 communicate. Terminal device 301 sends a data packet to switch 201 in the network. Since switch 201 does not store a flow table for packet forwarding, it sends a flow table request to server device 100. Upon receiving the request, server device 100 allocates a flow table for it. Switch 201 then forwards the data packet to terminal device 302 based on a flow table entry. When communication between terminal device 301 and terminal device 302 ends, the server device reclaims the flow table released by switch 201.

[0083] Among them, Figure 1B and Figure 1C In the application scenario shown, when the server device 100 allocates flow tables to the switch 201 and reclaims the flow tables released by the switch 201, the flow table management method provided in this application can be used, as detailed in the following embodiments.

[0084] In one alternative implementation, the server device 100 and the switch 200, as well as the switch 200 and the terminal device 300, can communicate via a wired network or a wireless network.

[0085] Terminal devices 300 include, but are not limited to, personal computers, mobile phones, tablets, laptops, e-book readers, smart medical devices, and vehicle-mounted terminals, as well as other computer devices with data transmission and reception capabilities. Furthermore, these computer devices can install various communication clients, which can be software, web pages, mini-programs, etc.

[0086] Switch 200 includes physical switches and virtual switches, and can be divided into access devices and transmission devices. Access devices are switches that are directly connected to service nodes, virtual machines or terminal devices in the SDN network (such as switches 201 and 202), while transmission devices are switches that are not access devices in the SDN network (such as switch 203).

[0087] The server-side device 100 serves as a backend server for the communication client, or as a dedicated server for data packet forwarding, querying, and modification; this application does not impose specific limitations. The server-side device 100 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0088] It should be noted that when the following embodiments of this application are applied to specific products or technologies, the data based on flow table management needs to obtain the permission or consent of the object, and the collection, use and processing of related data need to comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0089] See Figure 2 The flowchart below shows a flow table management method for packet processing provided in an embodiment of this application. The process mainly includes the following steps:

[0090] S201: The server device receives flow table management requests sent concurrently by multiple threads.

[0091] In a NUMA architecture, at least one thread among multiple threads on a virtual switch runs on a NUMA node.

[0092] For example, such as Figure 3 As shown, the server device contains two CPUs, denoted as CPU1 and CPU2, which correspond to local memory 1 and local memory 2, respectively, with the shortest access times. Local memory 2 is the non-local memory of CPU1, and local memory 1 is the non-local memory of CPU2. Both local memory 1 and local memory 2 are part of the server device's memory. CPU1 and local memory 1, as well as CPU2 and local memory 2, are considered as a NUMA node. CPU1 executes threads on virtual switch 1, allocating flow table information for threads 1 and 2 or storing flow table information released by threads 1 and 2 by accessing local memory 1; that is, threads 1 and 2 run on NUMA node 1. CPU2 executes threads on virtual switch 2, allocating flow table information for thread 3 or receiving flow table information released by thread 3 by accessing local memory 2; thread 3 runs on NUMA node 2.

[0093] In the embodiments of this application, multiple threads on the virtual switch can concurrently send flow table management requests to the server device, and the flow table management requests sent by different threads can be different.

[0094] In one alternative implementation, different threads on the same virtual switch can send the same type of flow table management request.

[0095] Still with Figure 3 For example, on virtual switch 1, the flow table management requests sent by thread 1 and thread 2 are both flow table allocation requests, that is, requesting the server device to allocate a flow table information to each of them.

[0096] In one alternative implementation, different threads on the same virtual switch can send different types of flow table management requests.

[0097] Still with Figure 3 For example, on virtual switch 1, the flow table management request sent by thread 1 is a flow table allocation request, that is, requesting the server device to allocate a flow table information for it; the flow table management request sent by thread 2 is a flow table release request, that is, requesting the server device to reclaim the flow table information allocated to it.

[0098] In one alternative implementation, different threads on different virtual switches can send the same type of flow table management request.

[0099] Still with Figure 3 For example, on virtual switch 1, the flow table management request sent by thread 1 is a flow table allocation request, that is, requesting the server device to allocate a flow table information for it; on virtual switch 2, the flow table management request sent by thread 3 is also a flow table allocation request, that is, requesting the server device to allocate a flow table information for it as well.

[0100] In one alternative implementation, different threads on different virtual switches can send different types of flow table management requests.

[0101] Still with Figure 3 For example, on virtual switch 1, the flow table management requests sent by thread 1 and thread 2 are both flow table allocation requests, that is, requesting the server device to allocate one flow table information to each of them; on virtual switch 2, the flow table management request sent by thread 3 is a flow table release request, that is, requesting the server device to reclaim the flow table information allocated to it.

[0102] Considering that high-speed, concurrent requests from multiple threads to allocate or release flow table information can generate intense competition, leading to errors or failures in the allocation and release of flow table information, requiring re-management of flow tables and reducing the performance of flow table management; at the same time, placing flow table information in the memory space of a specific NUMA node cannot avoid the performance degradation caused by excessive access across NUMA nodes under high concurrency.

[0103] To address the aforementioned issues, this application provides a cascaded circular queue data structure for storing and managing flow table information, achieving pooled management of flow table information. Specifically, each flow table information is treated as an independent element; the flow table information pool no longer cares about the specific content of each flow table information (such as the specific number of the flow table ID), but only about the position of each flow table information in the queue.

[0104] In the embodiments of this application, a cascaded ring queue data structure is used to store and manage flow table information. This eliminates the need for additional management or metadata to assist in allocating, releasing, or restoring flow table information. In other words, aside from the memory required to store the flow table information, virtually no additional memory space is needed. Compared to using a database to store and manage flow table information, this saves memory space, which is crucial for smart network interface cards (NICs). This is because smart NICs, unlike servers, have relatively higher memory usage costs.

[0105] For example, assuming each flow table ID only requires 4 bytes of memory, storing 100 flow table IDs would only require 400MB of memory. Compared to using a database, storing 100MB of flow table ID information can save approximately 800MB to 2.4GB of memory.

[0106] Meanwhile, the flow table queues at each level do not increase in size as the number of stored flow table IDs increases. Compared to the database, the memory space used by the flow table queues at each level is fixed and generally small.

[0107] For example, suppose a flow table queue stores 64 flow table IDs, and storing each flow table ID requires 4 bytes of memory space. With a total of 4 flow table queues, the memory space required to store the flow table information is 1KB.

[0108] In the embodiments of this application, the multiple flow table queues that make up the circular queue data structure are accessed with different priorities.

[0109] In one example, based on the two dimensions of threads and NUMA nodes in the NUMA architecture, the circular queue data structure is divided into three levels: a first-level flow table queue, a second-level flow table queue, and a third-level flow table queue. The first-level flow table queue has a higher priority than the second-level flow table queue, and the second-level flow table queue has a higher priority than the third-level flow table queue. Each first-level flow table queue corresponds to one thread and stores the flow table information available to that thread in its local memory; that is, each first-level flow table queue is exclusively used by one thread. Each second-level flow table queue corresponds to one NUMA node and stores the flow table information available to all threads running on that NUMA node in their local memory; that is, all threads of the virtual switch distributed on that NUMA node share one second-level flow table queue. The third-level flow table queue stores the flow table information available to each NUMA node in the total memory. The flow table information in each level of the flow table queue does not overlap.

[0110] Still with Figure 3 For example, the relationships between queues at each level of the flow table are as follows: Figure 4As shown, the server allocates a memory space in the total memory for pooled management of flow table information. This total memory space stores the third-level flow table queue. Based on the shortest access time, a local memory space is allocated from the total memory for each NUMA node. Specifically, local memory 1 of NUMA node 1 stores the second-level flow table queue corresponding to NUMA node 1, and local memory 2 of NUMA node 2 stores the second-level flow table queue corresponding to NUMA node 2. In local memory 1 of NUMA node 1, a portion of memory space (local memory 1') is allocated to thread 1 to store the first-level flow table queue corresponding to thread 1. At the same time, another portion of memory space (local memory 2') is allocated to thread 2 to store the first-level flow table queue corresponding to thread 2. In local memory 2 of NUMA node 2, a portion of memory space (local memory 3') is allocated to thread 3 to store the first-level flow table queue corresponding to thread 3.

[0111] In the embodiments of this application, when each virtual switch is started for the first time, the available flow table information is added to the third-level flow table queue in sequence, so that the third-level flow table queue initially stores all available flow table information for subsequent management of flow table allocation and release.

[0112] Taking the flow table information as the flow table ID as an example, the initial third-level flow table queue is as follows: Figure 5 As shown.

[0113] Based on the above-mentioned cascaded ring queue data structure, the corresponding flow table queues at each level can realize pooled management of flow table information, as detailed in steps S202-S203.

[0114] S202: For each thread, the server device determines the type of the flow table management request sent by that thread. If the type is a flow table allocation request, then execute S203; if the type is a flow table release request, then execute S204.

[0115] The operations on flow table information differ depending on the type of flow table management request. When the flow table management request is a flow table allocation request, a flow table information needs to be allocated to the thread. When the flow table management request is a flow table release request, a flow table information released by the thread needs to be reclaimed. Therefore, when performing flow table management, it is necessary to determine the type of flow table management request sent by each thread in advance.

[0116] S203: The server device allocates a flow table information to a thread without locking, based on the priority order of the flow table queues at all levels contained in the flow table information pool in the memory file system.

[0117] In the embodiments of this application, the flow table queues at each level constitute a cascaded circular queue data structure with different access priority orders. The first-level flow table queue has a higher access priority than the second-level flow table queue, and the second-level flow table queue has a higher access priority than the third-level flow table queue. Therefore, when allocating flow table information to each thread, one flow table information is preferentially allocated from the first-level flow table queue corresponding to each thread. Since each thread corresponds to one first-level flow table queue, there is no competition between threads for the same flow table information, thus allowing for lock-free concurrent allocation of flow table information to each thread, resulting in higher allocation efficiency. When there is no allocable flow table information in the first-level flow table queue of each thread, atomic instructions are used to allocate flow table information to each thread from the upper-level flow table queue according to priority order. Since atomic instructions are more lightweight than locks, even when allocating flow table information from the upper-level flow table queue, the allocation efficiency can still be guaranteed compared to the flow table allocation method using locks.

[0118] This embodiment stores the circular queue data structure of flow table queues at all levels in a memory file system (such as the memory file system of operating systems like Linux, Windows, or MAC), thereby mapping the memory file to the memory space of the virtual switch. This allows virtual switch threads to access the memory file to manage flow table information as if it were local memory, improving access speed compared to accessing ordinary files. Furthermore, it supports rapid recovery of flow table information by remapping the memory file. Thus, in the event of a hot upgrade or a virtual switch crash, simply remapping the memory file is sufficient to recover all flow table information. Data testing shows that the memory file mapping method can recover tens of millions of flow table records within 10ms.

[0119] The following example illustrates the allocation of stream table information for a single thread. For details, please refer to [link / reference]. Figure 6 It mainly includes the following steps:

[0120] S2031: Determine whether the first-level flow table queue of the thread itself is empty. If not, execute S2032; if so, execute S2033.

[0121] When a thread's own first-level flow table queue is not empty, it means that there is available flow table information in its own first-level flow table queue, and a flow table information can be directly allocated to it from the first-level flow table queue. When a thread's own first-level flow table queue is empty, it means that there is no available flow table information in its own first-level flow table queue, so a flow table information needs to be allocated to the thread from the parent flow table queue.

[0122] S2032: Allocate a flow table information for a thread from the first-level flow table queue.

[0123] For example, such as Figure 7A As shown, the first-level flow table queue of this thread is not empty, so a flow table ID can be directly assigned to it from the first-level flow table queue.

[0124] Since using a flow table queue to store flow table information does not require concern about the specific content of the flow table information (such as the specific number of the flow table ID), it is only necessary to care about the position of each flow table information in the flow table queue. Thus, by maintaining head and tail pointers, the flow table queue can be cyclical, and the flow table information is always obtained from the position pointed to by the head pointer during allocation, thereby realizing the "first-in, first-out" queue semantics and ensuring the predictability of flow table information allocation.

[0125] Specifically, when allocating a flow table information to the thread from the first-level flow table queue, the process involves obtaining the current first head pointer in the first-level flow table queue, allocating the flow table information at the position pointed to by the first head pointer to the thread, and then pointing the first head pointer to the position of the next flow table information.

[0126] For example, such as Figure 7B As shown, a flow table ID is directly allocated to thread 1 from its first-level flow table queue. Before allocation, both the head pointer and tail pointer in the current first-level flow table queue point to the first position in the queue. Therefore, the flow table ID1 at the first position is allocated to thread 1. After allocation, the first position is empty and cannot be allocated again. At this point, the head pointer and tail pointer can be moved one position to the right, that is, the head pointer and tail pointer point to the second position. By pointing the head pointer and tail pointer to the same position, the first-level flow table queue of thread 1 is looped.

[0127] S2033: Determine whether the second-level flow table queue of the NUMA node where the thread is located is empty. If not, execute S2034; if yes, execute S2035.

[0128] When the thread's own first-level flow table queue is empty, it needs to allocate a flow table information for the thread from the parent flow table queue. The parent flow table queue contains the second-level flow table queue of the NUMA node running it and the third-level flow table queue of each NUMA node. According to the priority order, the second-level flow table queue needs to be accessed first. Therefore, it is necessary to determine whether the second-level flow table queue is empty.

[0129] S2034: Allocate multiple flow table information from the second-level flow table queue and store them in the first-level flow table queue of the thread itself, and allocate one flow table information for the thread from the first-level flow table queue.

[0130] When the second-level flow table queue of the NUMA node running the thread is not empty, it indicates that a flow table information can be allocated for the thread from the second-level flow table queue, without needing to access the third-level flow table queue.

[0131] For example, if thread 1's own first-level flow table queue is empty, but the second-level flow table queue of the NUMA node running it is not empty, then... Figure 7C As shown, firstly, five flow table IDs are allocated from the second-level flow table queue to the first-level flow table queue of thread 1, and then one flow table information is allocated to thread 1 from the first-level flow table queue.

[0132] Specifically, when allocating multiple flow table information from the second-level flow table queue to the first-level flow table queue, the current second head pointer in the second-level flow table queue is obtained, and the flow table information at the position pointed to by the second head pointer, as well as at least one flow table information thereafter, is stored in the first-level flow table queue of the thread itself, and the second head pointer is set to point to the position of the first flow table information among the remaining flow table information.

[0133] For example, such as Figure 7D As shown, when allocating a flow table ID from the second-level flow table queue of the NUMA node running thread 1, before allocation, the second head pointer and the second tail pointer in the current second-level flow table queue both point to the first position of the queue. Therefore, the flow table ID1 at the first position and the four flow table IDs thereafter are allocated to the first-level flow table queue of thread 1. After allocation, the second head pointer and the second tail pointer are moved 5 positions to the right, that is, the second head pointer and the second tail pointer point to the sixth position. By pointing the second head pointer and the second tail pointer to the same position, the second-level flow table queue of the NUMA node is cyclical.

[0134] The process of allocating a flow table information for the thread from the first-level flow table queue after allocating the second-level flow table queue to the first-level flow table queue is described in S2032 and will not be repeated here.

[0135] S2035: Allocate multiple flow table information from the third-level flow table queue and store them in the second-level flow table queue of the NUMA node where the thread is located. Also, allocate multiple flow table information from the second-level flow table queue and store them in the first-level flow table queue of the thread itself. Allocate one flow table information for the thread from the first-level flow table queue.

[0136] When the second-level flow table queue of the NUMA node running the thread is empty, it needs to access the third-level flow table queue to allocate a flow table information for it.

[0137] For example, when both the first-level flow table queue of thread 1 itself and the second-level flow table queue of the NUMA node running it are empty, then, as Figure 7EAs shown, firstly, 17 flow table IDs are allocated from the third-level flow table queue to the second-level flow table queue of the NUMA node where thread 1 is located. Then, 5 flow table IDs are allocated from the second-level flow table queue to the first-level flow table queue of thread 1 itself. Finally, 1 flow table information is allocated to thread 1 from the first-level flow table queue.

[0138] Specifically, when allocating multiple flow table information from the third-level flow table queue to the second-level flow table queue, the current third head pointer in the third-level flow table queue is obtained, and the flow table information at the position pointed to by the third head pointer, as well as at least one flow table information thereafter, is stored in the second-level flow table queue of the NUMA node where the thread is distributed. The third head pointer is then set to point to the position of the first flow table information among the remaining flow table information.

[0139] For example, such as Figure 7F As shown, before allocation, the third head pointer and the third tail pointer in the current third-level flow table queue both point to the first position of the queue. Therefore, the flow table ID1 at the first position and the subsequent 16 flow table IDs are allocated to the second-level flow table queue of the NUMA node running thread 1. After allocation, the third head pointer and the third tail pointer are shifted 17 positions to the right, that is, the second head pointer and the third tail pointer point to the eighteenth position. By making the third head pointer and the third tail pointer point to the same position, the third-level flow table queue is cyclical.

[0140] In the flow table management method provided in this application embodiment, since each first-level flow table queue is exclusively used by one thread and will not be accessed by other threads, flow table information can be efficiently and concurrently allocated to each thread from each first-level flow table queue without locking or using atomic instructions. Atomic instructions are only used when the first-level flow table queue is empty and the upper-level flow table queue needs to be accessed for flow table information allocation. Memory access across NUMA nodes may only occur when flow table information is allocated from the third-level flow table. In this way, under high concurrency, the number of memory accesses across NUMA nodes can be reduced to the greatest extent, improving the access performance of the flow table queue.

[0141] For example, when allocating 4096 flow table entries from the third-level flow table queue to the second-level flow table queue of a thread's NUMA node, and when allocating 4096 flow table entries from the second-level flow table queue to the first-level flow table queue of a thread, only 1 / 64 of the memory accesses require atomic instructions, and on average, there is only one cross-NUMA node memory access every 256K allocations.

[0142] S204: The server device uses an atomic instruction to store the flow table information carried in the flow table release request into the third-level flow table queue.

[0143] Since each first-level flow table queue is exclusively used by one thread, while the flow table information in the third-level flow table queue can be allocated to lower-level flow table queues, in order to ensure that the released flow table information can be reassigned to other threads, when a thread's flow table management request is a flow table release request, the flow table information carried by the flow table release request can be stored in the third-level flow table queue with the lowest priority.

[0144] The release of flow table information often occurs during the network traffic aging process and is generally not in the critical path affecting the performance of the virtual switch. To ensure first-in-first-out semantics, the server device uses atomic instructions to store the released flow table information in the third-level flow table queue for each thread, and the release speed of flow table information is less than the allocation speed of flow table information.

[0145] In practice, the current fourth head pointer in the third-level flow table queue is obtained, the flow table information carried by the flow table release request is stored in the position pointed to by the fourth head pointer, and the fourth head pointer is moved to the next position. This ensures that the released flow table information will only be reassigned after other flow table information before the released flow table information has been reassigned.

[0146] For example, such as Figure 8A As shown, before thread 3 releases flow table ID100, in the current third-level flow table queue, both the fourth head pointer and the fourth tail pointer point to the 100th position. This position is empty as it does not store a flow table ID. Therefore, the released flow table ID100 can be stored at this position. When the server device receives the flow table release request from thread 3, it places flow table ID100 at the currently pointed-to position according to the positions of the fourth head pointer and the fourth tail pointer, and then moves both the fourth head pointer and the fourth tail pointer one position to the right. Figure 8B As shown.

[0147] Depend on Figure 8A and Figure 8B It can be seen that the third-level flow table queue is different from the first-level flow table queue and the second-level flow table queue. The third-level flow table queue includes two head pointers and two tail pointers. The third head pointer and the third tail pointer are used to manage the allocation of flow table information in a cyclic manner, and the fourth head pointer and the fourth tail pointer are used to manage the release of flow table information in a cyclic manner.

[0148] In the embodiments of this application, by maintaining head pointers in the flow table queues at each level, flow table information allocation always starts from the position pointed to by the head pointer, and flow table information is always stored at the position pointed to by the head pointer when it is released. This achieves the ordered allocation and release of flow table information while minimizing thread contention for flow table information and the use of atomic instructions, ensuring the "first-in, first-out" queue semantics, thereby improving the predictability of flow table information allocation and release. This is more friendly to the pipeline design of virtual switches and smart network cards. Furthermore, by pointing the tail pointer corresponding to each head pointer to the same position in the flow table queue, a bidirectional circular flow table queue is formed, enabling the flow table queue to be reused.

[0149] In one example, after allocating a flow table information to each thread without locking, the data packets transmitted by each thread are processed based on their respective flow table information. The processing operation includes one of the following: finding, forwarding, modifying, and deleting data packets. The data packets include one of the following: image data packets, voice data packets, text data packets, and web page data packets.

[0150] Taking the forwarding of text data packets between the first thread and the second thread as an example, such as Figure 9 As shown, the first thread packages the text data input by object A through terminal device 1 into a text data packet, and sends the text data packet to the server device based on the first flow table information allocated to it. The server device forwards the text data packet to the second thread based on the second flow table information allocated to the second thread, and after decoding by terminal device 2, it displays it to object B.

[0151] Based on the same technical concept, this application provides a schematic diagram of a flow table management device for packet processing. This flow table management device can implement the above-mentioned flow table management method for packet processing and achieve the same technical effect.

[0152] See Figure 10 The flow table management device includes a request receiving module 1001 and a flow table management module 1002, wherein:

[0153] The request receiving module 1001 is used to receive flow table management requests sent concurrently by multiple threads, wherein at least one of the multiple threads runs on a NUMA node;

[0154] The flow table management module 1002 is used to allocate a flow table information to each thread without locking when the thread's flow table management request is a flow table allocation request, based on the priority order of the flow table queues at each level contained in the flow table information pool in the memory file system; and when the thread's flow table management request is a flow table release request, it uses atomic instructions to store the flow table information carried in the flow table release request into the third-level flow table queue.

[0155] In this system, each first-level flow table queue stores flow table information available to a thread in its local memory, each second-level flow table queue stores flow table information available to each thread on a NUMA node in its local memory, and the third-level flow table queue stores flow table information available to each NUMA node in the total memory. The flow table information in each level of the flow table queue does not overlap. The priority of the first-level flow table queue is higher than that of the second-level flow table queue, and the priority of the second-level flow table queue is higher than that of the third-level flow table queue.

[0156] Optionally, the flow table management module 1002 is specifically used for:

[0157] When the thread's own first-level flow table queue is not empty, allocate a flow table information for the thread from the first-level flow table queue;

[0158] When the thread's own first-level flow table queue is empty, a flow table information is allocated to the thread from the parent flow table queue.

[0159] Optionally, the flow table management module 1002 is specifically used for:

[0160] When the second-level flow table queue of the NUMA node where the thread is located is not empty, multiple flow table information is allocated from the second-level flow table queue and stored in the first-level flow table queue of the thread itself, and one flow table information is allocated to the thread from the first-level flow table queue.

[0161] When the second-level flow table queue of the NUMA node where the thread resides is empty, multiple flow table information is allocated from the third-level flow table queue and stored in the second-level flow table queue of the NUMA node where the thread resides. Multiple flow table information is also allocated from the second-level flow table queue and stored in the first-level flow table queue of the thread itself. Finally, one flow table information is allocated to the thread from the first-level flow table queue.

[0162] Optionally, the flow table management module 1002 is specifically used for:

[0163] Get the current third head pointer in the third-level flow table queue, store the flow table information at the position pointed to by the third head pointer, as well as at least one flow table information thereafter, into the second-level flow table queue of the NUMA node where the thread is located, and set the third head pointer to the position of the first flow table information in the remaining flow table information.

[0164] Optionally, the flow table management module 1002 is specifically used for:

[0165] Get the current second head pointer in the second-level flow table queue, store the flow table information at the position pointed to by the second head pointer, as well as at least one flow table information thereafter, into the thread's own first-level flow table queue, and set the second head pointer to the position of the first flow table information among the remaining flow table information.

[0166] Optionally, the flow table management module 1002 is specifically used for:

[0167] Get the current first head pointer in the first-level flow table queue, assign the flow table information at the position pointed to by the first head pointer to the thread, and then point the first head pointer to the position of the next flow table information.

[0168] Optionally, the flow table management module 1002 is specifically used for:

[0169] Get the current fourth head pointer in the third-level flow table queue, store the flow table information carried in the flow table release request at the position pointed to by the fourth head pointer, and move the fourth head pointer to the next position.

[0170] Optionally, storing the flow table information carried in the flow table release request into the third-level flow table queue is slower than allocating flow table information to other threads without locks.

[0171] Optionally, a data processing module 1003 is also included, which is used to process the data packets transmitted by each thread based on the flow table information of each thread. The processing operation includes one of searching, forwarding, modifying and deleting data packets. The data packets include one of image data packets, voice data packets, text data packets and web page data packets.

[0172] This application provides a flow table management device for packet processing, which employs a cascaded ring queue data structure to store and manage flow tables. In each level of the flow table queue, each first-level flow table queue stores flow table information available to a single thread in its local memory. This means each first-level flow table queue is exclusively used by one thread, preventing contention for flow table information with other threads. Therefore, for each thread requesting flow table allocation, flow table information can be allocated concurrently from its respective first-level flow table queue without locks, improving allocation efficiency. Furthermore, when no flow table information is available in the first-level flow table queue, flow table information can be allocated sequentially from the second-level and third-level flow table queues. This cascading queue approach ensures the stability of flow table information allocation for each thread. When a thread's flow table management request is a flow table release request, an atomic instruction is used to store the flow table information carried in the release request into the lowest-priority third-level flow table queue. Meanwhile, for each thread requesting the release of flow table information, the flow table information released by each thread is stored in the lowest-priority third-level flow table queue. This ensures that after unallocated flow table information is allocated, newly released flow table information can be reallocated, improving the utilization rate of flow table information. Furthermore, mapping the cascaded circular queue data structure onto the memory file system enables pooled management of flow table information. This allows access to the memory file system to allocate or release flow table information as if it were local memory, improving management speed.

[0173] Based on the same inventive concept as the above-described method embodiments, this application also provides an electronic device. In one embodiment, the electronic device can be a server device or a smart network interface card (NIC). In this embodiment, the structure of the electronic device can be as follows: Figure 11 As shown, it includes a memory 1101, a communication module 1103, and one or more processors 1102.

[0174] The memory 1101 is used to store computer programs executed by the processor 1102. The memory 1101 may mainly include a program storage area and a data storage area, wherein the program storage area may store the operating system and the operating instruction set, etc.

[0175] Memory 1101 may be volatile memory, such as random-access memory (RAM); memory 1001 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1001 may be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1101 may be a combination of the above-described memories.

[0176] Processor 1102 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 1102 is used to implement the flow table management method for packet processing described above when calling computer programs stored in memory 1101.

[0177] The communication module 1103 is used to communicate with terminal devices and other servers.

[0178] This application embodiment does not limit the specific connection medium between the memory 1101, communication module 1103, and processor 1102. This application embodiment... Figure 11 The memory 1101 and the processor 1102 are connected via a bus 1104, and the bus 1104 is in Figure 11 The diagram uses thick lines to describe the connections between other components; these are for illustrative purposes only and should not be considered limiting. Bus 1104 can be divided into address bus, data bus, control bus, etc. For ease of description, Figure 11 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0179] The memory 1101 stores a computer storage medium containing computer-executable instructions for implementing the flow table management method for packet processing according to embodiments of this application. The processor 1102 executes the steps of the aforementioned flow table management method for packet processing.

[0180] In some possible implementations, various aspects of the data classification method provided in this application can also be implemented as a program product, comprising a computer program that, when run on an electronic device, causes the electronic device to perform the steps of the flow table management method for packet processing according to various exemplary embodiments of this application described above. For example, the electronic device can perform actions such as... Figure 2 The steps are shown in the figure.

[0181] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0182] The program product of the embodiments of this application may employ a portable compact disk read-only memory and include a computer program, and may run on an electronic device. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0183] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.

[0184] Computer programs contained on readable media may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0185] Computer programs for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The computer program can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device.

[0186] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing a computer-usable computer program.

[0187] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0188] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A flow table management method for packet processing, characterized in that, The method includes: Receive flow table management requests sent concurrently by multiple threads, wherein at least one of the multiple threads runs on a non-uniform memory access NUMA node; For each thread, perform the following operations: When the thread's flow table management request is a flow table allocation request, a flow table information is allocated to the thread without locking, based on the priority order of the flow table information pool at each level in the memory file system. Specifically, in each level of flow table queue, each first-level flow table queue stores flow table information available to the thread itself in its local memory; each second-level flow table queue stores flow table information available to each thread on a NUMA node in its local memory; and each third-level flow table queue stores flow table information available to each NUMA node in the total memory. The flow table information in each level of flow table queue does not overlap. The priority of the first-level flow table queue is higher than that of the second-level flow table queue, and the priority of the second-level flow table queue is higher than that of the third-level flow table queue. When the thread's flow table management request is a flow table release request, an atomic instruction is used to store the flow table information carried by the flow table release request into the third-level flow table queue. The method of allocating a flow table information to the thread without locking, based on the priority order of the flow table information pool in memory, includes: When the first-level flow table queue of the thread itself is not empty, allocate a flow table information for the thread from the first-level flow table queue; When the first-level flow table queue of the thread itself is empty, if the second-level flow table queue of the NUMA node where the thread is located is not empty, then multiple flow table information is allocated from the second-level flow table queue and stored in the first-level flow table queue of the thread itself, and one flow table information is allocated for the thread from the first-level flow table queue; otherwise, multiple flow table information is allocated from the third-level flow table queue and stored in the second-level flow table queue of the NUMA node where the thread is located, and multiple flow table information is allocated from the second-level flow table queue and stored in the first-level flow table queue of the thread itself, and one flow table information is allocated for the thread from the first-level flow table queue.

2. The method as described in claim 1, characterized in that, The step of allocating multiple flow table information from the third-level flow table queue and storing them in the second-level flow table queue of the NUMA node where the thread resides includes: Obtain the current third head pointer in the third-level flow table queue, store the flow table information at the position pointed to by the third head pointer, as well as at least one flow table information thereafter, into the second-level flow table queue of the NUMA node where the thread is located, and set the third head pointer to the position of the first flow table information in the remaining flow table information.

3. The method as described in claim 1, characterized in that, The step of allocating multiple flow table information from the second-level flow table queue and storing them in the thread's own first-level flow table queue includes: Obtain the current second head pointer in the second-level flow table queue, store the flow table information at the position pointed to by the second head pointer, as well as at least one flow table information thereafter, into the first-level flow table queue of the thread itself, and set the second head pointer to the position of the first flow table information among the remaining flow table information.

4. The method as described in claim 1, characterized in that, The step of allocating a flow table information for the thread from the first-level flow table queue includes: Obtain the current first head pointer in the first-level flow table queue, assign the flow table information at the position pointed to by the first head pointer to the thread, and point the first head pointer to the position of the next flow table information.

5. The method as described in claim 1, characterized in that, The step of using atomic instructions to store the flow table information carried in the flow table release request into the third-level flow table queue includes: Obtain the current fourth head pointer in the third-level flow table queue, store the flow table information carried by the flow table release request at the position pointed to by the fourth head pointer, and move the fourth head pointer to the next position.

6. The method as described in claim 1, characterized in that, The release speed of storing the flow table information carried in the flow table release request into the third-level flow table queue is less than the allocation speed of allocating a flow table information to another thread without locks.

7. The method as described in claim 1, characterized in that, After allocating a separate flow table for each thread without locking, the method further includes: Based on the flow table information of each thread, the data packets transmitted by each thread are processed. The processing operation includes one of searching, forwarding, modifying and deleting the data packets. The data packets include one of image data packets, voice data packets, text data packets and web page data packets.

8. A flow table management device for packet processing, characterized in that, include: The request receiving module is used to receive flow table management requests sent concurrently by multiple threads, wherein at least one of the multiple threads runs on a non-uniform memory access NUMA node; The flow table management module is used to allocate a flow table information to each thread without locking when the thread's flow table management request is a flow table allocation request, based on the priority order of the flow table queues at each level contained in the flow table information pool in the memory file system; and when the thread's flow table management request is a flow table release request, it uses atomic instructions to store the flow table information carried by the flow table release request into the third-level flow table queue. In this system, each first-level flow table queue stores flow table information available to a thread in its local memory, each second-level flow table queue stores flow table information available to each thread on a NUMA node in its local memory, and the third-level flow table queue stores flow table information available to each NUMA node in the total memory. The flow table information in each level of the flow table queue does not overlap with each other. The priority of the first-level flow table queue is higher than that of the second-level flow table queue, and the priority of the second-level flow table queue is higher than that of the third-level flow table queue. The flow table management module is specifically used for: When the first-level flow table queue of the thread itself is not empty, allocate a flow table information for the thread from the first-level flow table queue; When the first-level flow table queue of the thread itself is empty, if the second-level flow table queue of the NUMA node where the thread is located is not empty, then multiple flow table information is allocated from the second-level flow table queue and stored in the first-level flow table queue of the thread itself, and one flow table information is allocated for the thread from the first-level flow table queue; otherwise, multiple flow table information is allocated from the third-level flow table queue and stored in the second-level flow table queue of the NUMA node where the thread is located, and multiple flow table information is allocated from the second-level flow table queue and stored in the first-level flow table queue of the thread itself, and one flow table information is allocated for the thread from the first-level flow table queue.

9. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of any of the methods described in claims 1-7.

10. A computer-readable storage medium, characterized in that, It includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of any of the methods described in claims 1-7.

11. A computer program product, characterized in that, The method includes a computer program stored in a computer-readable storage medium; when a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the electronic device to perform the steps of any one of the methods of claims 1-7.

Images