Flow table offloading system, device and cluster

Abstract

The present application provides a flow table unloading system, device and cluster. The system includes: a processor, which is used to run a virtual switch, which is a switch virtualized based on the hardware resources of the processor, and the virtual switch is used to unload the flow table to the callback list of the network card; the network card includes multiple physical functions and a shared pool, the shared pool includes multiple shared blocks, the callback list of the network card includes multiple physical callback lists, and there is a one-to-one correspondence between the multiple physical callback lists and the multiple physical functions. The physical callback list includes multiple storage blocks, and any one of the multiple shared blocks is a storage block that can be assigned to any physical callback list. The above scheme can effectively improve the insertion and search efficiency of the flow table.

Description

Technical Field

[0001] The present application relates to the field of data communications, and in particular to a flow table unloading system, device, and cluster. Background Art

[0002] With the development of cloud computing networks, its extensive business needs have led to the rapid growth of data centers and a sharp increase in data traffic. In order to meet the needs of high-performance business forwarding, it is imperative to use a virtual switch (Open vSwitch, OVS) for data forwarding.

[0003] The traffic control (tc) flow table of the virtual switch is stored in the callback list of the network card. The callback list includes multiple storage blocks, each of which stores a flow table. Since there is only one callback list globally, the insertion and search efficiency is not high when the data volume is large. Summary of the invention

[0004] The present application provides a flow table unloading system, device and cluster, which can effectively improve the efficiency of flow table insertion and search.

[0005] In a first aspect, a flow table unloading system is provided, including:

[0006] A processor, configured to run a virtual switch, wherein the virtual switch is a switch virtualized based on hardware resources of the processor, and the virtual switch is configured to offload a flow table to a callback list of a network card;

[0007] A network card includes multiple physical functions and a shared pool, wherein the shared pool includes multiple shared blocks, a callback list of the network card includes multiple physical callback lists, and there is a one-to-one correspondence between the multiple physical callback lists and the multiple physical functions. The physical callback list includes multiple storage blocks, and any one of the multiple shared blocks is a storage block that can be allocated to any physical callback list.

[0008] In the above scheme, different physical functions correspond to different physical callback lists. When operations such as search or insertion are required, only the same physical callback list is needed, which greatly reduces the search scope and improves the search efficiency. In addition, the network card also includes multiple shared blocks. When a physical callback list is not enough, the shared block can be allocated to the physical callback list.

[0009] In some possible designs, the multiple physical callback lists include a first physical callback list, a first physical function corresponds to the first physical callback list, and the first physical function belongs to the multiple physical functions.

[0010] The virtual switch is used to offload a first flow table to a callback list of the network card, wherein an ingress port of the first flow table is the first physical function;

[0011] The network card is used for storing the first flow table in a free storage block of the first physical callback list when there is a free storage block in the first physical callback list; and for allocating a first shared block to the first physical callback list and storing the first flow table in a first shared block allocated to the first physical callback list when there is no free storage block in the first physical callback list.

[0012] In some possible designs, the network card is used to search for the first flow table in the first physical callback list when receiving an instruction to delete the first flow table, and when the first flow table is found, delete the first flow table and return the first shared block to the shared pool.

[0013] In some possible designs, the network card is further used to delete the flow table in each storage block in the first physical callback list upon receiving an instruction to delete all flow tables of the first physical function.

[0014] In the above solution, when all flow tables under a physical function need to be deleted, it is only necessary to delete all flow tables under the physical callback list, without having to search in a large range for deletion.

[0015] In some possible designs, the multiple physical callback lists include a first physical callback list and a second physical callback list, the first physical function corresponds to the first physical callback list, the second physical function corresponds to the second physical callback list, the first physical function and the second physical function belong to the multiple physical functions, and the first physical function and the second physical function constitute a binding port;

[0016] The virtual switch is used to unload the second flow table to the callback list of the network card, wherein the ingress port of the second flow table is the binding port;

[0017] The network card is further configured to store the second flow table in the first physical callback list when the number of free storage blocks in the first physical callback list is greater than the number of free storage blocks in the second physical callback list;

[0018] The network card is further configured to store the second flow table in the second physical callback list when the number of free storage blocks in the second physical callback list is greater than the number of free storage blocks in the first physical callback list.

[0019] In the above solution, the flow table of the bound port can be stored in a relatively idle physical callback list, thereby improving the utilization rate of the physical callback list.

[0020] In some possible designs, the network card is also used to delete the second flow table from the first physical callback list upon receiving a deletion command for the second flow table and if the second flow table is stored in the first physical callback list; and to delete the second flow table from the second physical callback list upon receiving a deletion command for the second flow table and if the second flow table is stored in the second physical callback list.

[0021] In some possible designs, the network card is also used to store the correspondence between the second flow table and the first physical callback list when the second flow table is stored in the first physical callback list; and to store the correspondence between the second flow table and the second physical callback list when the second flow table is stored in the second physical callback list.

[0022] In some possible designs, the number of shared blocks in the shared pool is greater than the number of storage blocks in any physical callback list.

[0023] In a second aspect, a computing device is provided, including a flow table unloading system and a storage unit, wherein the flow table unloading system and the storage unit can communicate with each other, and the flow table unloading system is a system as described in any one of the first aspects.

[0024] In a third aspect, a computing device cluster is provided, including a flow table unloading system and a storage unit, wherein the flow table unloading system and the storage unit can communicate with each other, and the flow table unloading system is a system as described in any one of the first aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the background technology, the drawings required for use in the embodiments of the present invention or the background technology will be described below.

[0026] Figure 1 It is a structural diagram of a software defined network (SDN) provided in this application;

[0027] Figure 2 It is a structural schematic diagram of a flow table unloading system provided by this application;

[0028] Figure 3 It is a structural diagram of a callback list provided by this application;

[0029] Figure 4It is a structural schematic diagram of a storage block provided by the present application;

[0030] Figure 5 It is a structural schematic diagram of a computing device provided by this application. DETAILED DESCRIPTION

[0031] The embodiments of the present invention are described below in conjunction with the accompanying drawings in the embodiments of the present invention. The terms used in the implementation mode of the present invention are only used to explain the specific embodiments of the present invention, and are not intended to limit the present invention.

[0032] See also Figure 1 , Figure 1 This is a schematic diagram of the structure of an SDN provided by this application. Figure 1 As shown, the software defined network of the present application includes: an SDN controller 110 and an open virtual switch (open vSwitch, OVS) 120.

[0033] The SDN controller 110 is a core component in the SDN architecture, which is responsible for the centralized management and control of the entire network. The SDN controller separates the control plane of the network from the data plane, thereby providing a more flexible, programmable and scalable network management method. The main functions of the SDN controller include: managing the control plane of the entire network, including topology discovery, route calculation, flow table delivery, etc. Specifically, the SDN controller 110 collects the topology information of the network by communicating with OVS120, calculates the route according to the application requirements, and then delivers the flow table to OVS120. Secondly, the SDN controller 110 can dynamically adjust the network routing and traffic distribution according to the characteristics and requirements of the traffic, thereby achieving load balancing, congestion control and service quality assurance of the traffic; it can implement security measures such as access control, traffic filtering and intrusion detection, and respond to network security events in a timely manner to protect the network from malicious attacks and data leakage threats, etc. The SDN controller 110 can be a physical device or a virtual device. When the number of SDN controllers 110 is multiple, physical devices and virtual devices can also be used in combination. The SDN controller 110 can run in physical servers, virtual machines, containers, cloud platforms, and bare metal servers.

[0034] OVS120 is an open source virtual switch software that implements a flexible, programmable and scalable switch platform for communicating with the SDN controller through the OpenFlow protocol, receiving the flow table issued by the SDN controller 110, and implementing traffic forwarding and routing according to the flow table. OVS120 supports packet switching and routing in Layer 2 and Layer 3 networks, so OVS120 supports the processing of Ethernet data frames and data packets, etc. OVS120 can run on physical servers, virtual machines, containers, cloud platforms, and bare metal servers. OVS120 can also be used in combination with physical switches, etc.

[0035] The SDN controller 110 and OVS120 can both be set in a container. In this case, the SDN controller 110 and OVS120 can be concentrated in the same container or distributed in different containers. The SDN controller 110 and OVS120 can both be set in a virtual machine. In this case, the SDN controller 110 and OVS120 can be concentrated in the same virtual machine or distributed in different virtual machines. The SDN controller 110 and OVS120 can both be set in a server. In this case, the SDN controller 110 and OVS120 can be concentrated in the same server or distributed in different servers. The SDN controller 110 and OVS120 can both be set in a bare metal server. In this case, the SDN controller 110 and OVS120 can be concentrated in the same bare metal server or distributed in different bare metal servers. Alternatively, the SDN controller 110 is set in a container, and OVS120 is set in any one of a virtual machine, a server, and a bare metal server. The SDN controller 110 is set in the virtual machine, and the OVS 120 is set in any one of the container, the server, and the bare metal server. The SDN controller 110 is set in the server, and the OVS 120 is set in any one of the container, the virtual machine, and the bare metal server. The SDN controller 110 is set in the bare metal server, and the OVS 120 is set in any one of the container, the virtual machine, and the server.

[0036] The message of the local end can be forwarded to the remote end through the above software defined network. Among them, the local end can be integrated with at least one of OVS120 and SDN controller 110 in the same server. The remote end can also be integrated with at least one of OVS120 and SDN controller 110 in the same server.

[0037] The above OVS120 is usually virtualized using computing resources (e.g., processor), storage resources, and network resources (e.g., network card) of computing devices, and in order to improve the forwarding performance of OVS120, it is often necessary to set up offloading hardware for acceleration. Therefore, the processor, offloading hardware, and network card can form a message transmission system.

[0038] In the above example, the controller is an SDN controller and the forwarding device is OVS. In actual applications, the controller can also be other open source controllers such as OpenStack, Kubernetes, etc. In addition, the controller can also be a privately developed controller, and the forwarding device can also be other privately developed forwarding devices, etc., which are not specifically limited here.

[0039] See also Figure 2 , Figure 2 Schematic diagram of a flow table unloading system provided by this application. Figure 2 As shown, the flow table unloading system of the present application includes a processor 11 and a network card 13.

[0040] The processor 11 is used to communicate with the network card and run the virtual switch. Optionally, a data plane development kit can also be run. The virtual switch is a switch virtualized based on the hardware resources of the processor. The data plane development kit is used to assist the virtual switch to improve the performance of the virtual switch. The processor 11 is a computing core and a control core, which can handle complex situations. The processor 11 can be a very large-scale integrated circuit. An operating system and other software programs are installed in the processor 11, so that the processor 11 can access the memory and various PCIE devices. The processor 11 can quickly access the memory through the on-chip bus. The processor 11 may include one or more processor cores. In one implementation, the processor 11 may be a multi-core chip, that is, a chip containing multiple processing cores. In another implementation, the processor 11 may include one or more processor cores. It can be a chip with one processing core. The processor 11 unloads the flow table to the callback list of the network card 13.

[0041] The network card 13 is used to query the flow table and provide hardware resources for network communication. Because it has a Media Access Control Address (MAC) address, it belongs between Layer 1 and Layer 2 of the Open System Interconnection (OSI) model. It allows users to connect to each other through cables or wirelessly. Each network card has a unique 48-bit serial number called a MAC address, which is written in a read-only memory on the card. Here, the network card can be a Field Programmable Gate Array (FPGA) network card or an Application Specific Integrated Circuit (ASIC) network card, etc. The network card 13 is hardware virtualized through Single Root I / O Virtualization (SR-IOV). SR-IOV allows a physical high-speed serial computer expansion bus standard (Peripheral Component Interconnect Express, PCIe) device (such as the network card 13) to be presented as multiple independent virtual devices, each of which can be directly allocated to a virtual machine for use. SR-IOV usually includes physical functions (PF) and virtual functions (VF). PF is used to manage VF, while VF can be directly allocated to virtual machines for use. Each PF is independent of each other.

[0042] like Figure 3As shown, the network card can create a physical callback list for each PF, and each physical callback list includes multiple storage blocks. The network card can also include a shared pool, and the shared pool includes multiple shared blocks. Any shared block in the multiple shared blocks is a storage block that can be allocated to any physical callback list. For example, assume that the specification of the callback list is 100,000 storage blocks and the number of physical functions is 4. At this time, a first physical callback list is created for the first physical function, and the number of storage blocks in the first physical callback list is 10,000, so the index range of the storage blocks in the first physical callback list is [1, 10,000]; a second physical callback list is created for the second physical function, and the number of storage blocks in the second physical callback list is 10,000, so the index range of the storage blocks in the second physical callback list is [10,000+1, 20,000]; a third physical callback list is created for the third physical function, and the number of storage blocks in the third physical callback list is 10,000, so the index range of the storage blocks in the third physical callback list is [20,000+1, 30,000]; a fourth physical callback list is created for the fourth physical function, and the number of storage blocks in the fourth physical callback list is 10,000, so the index range of the storage blocks in the fourth physical callback list is [30,000+1, 40,000]. The shared pool includes 60,000 storage blocks, so the index range of the storage blocks in the shared pool is [40,000+1, 100,000]. Each physical function is only allocated 10,000 storage blocks because only the most basic physical function specification requirements need to be met. That is to say, each physical function is guaranteed to have its own physical callback list, but the allocation cannot be too large. Because some physical functions may not have flow tables, allocating too large will cause waste. After each physical function uses up its own 10,000 storage blocks, it can apply for shared blocks from the shared pool. Figure 4 As shown, the storage block includes an index, an ingress port, an action, and an egress port. The index is the identifier of the flow table entry. The ingress port is the physical port or virtual port when the data packet enters the virtual switch. The port where the data packet arrives in the virtual switch is called the "ingress port", which is the entrance for the data packet to enter the network device. The action refers to the operation to be performed by the data packet after matching the flow table entry. The egress port is the port when the data packet leaves the switch, and it is the exit port where the data packet finally leaves the virtual switch.

[0043] When the virtual switch is used to unload the first flow table to the callback list of the network card, and the ingress port of the first flow table is the first physical function, if there is an idle storage block in the first physical callback list, the network card stores the first flow table in the idle storage block of the first physical callback list; if there is no idle storage block in the first physical callback list, the network card allocates the first shared block in the shared pool to the first physical callback list, and stores the first flow table in the first shared block allocated to the first physical callback list. It is not difficult to understand that the same is true for storing other flow tables in other physical callback lists, which will not be described in detail here.

[0044] Since the specification of the first physical callback list is much smaller than that of the entire callback list, for example, the specification of the first physical callback list is 10,000, and the specification of the entire callback list is 100,000, at this time, the efficiency of inserting or searching the flow table of the first physical function in the first physical callback list is relatively high.

[0045] When receiving the instruction to delete the first flow table, the first flow table is searched in the first physical callback list. When the first flow table is found, the first flow table is deleted and the first shared block is returned to the shared pool. Here, when the first shared block is returned to the shared pool, the first shared block can be provided to other physical callback lists for use, and of course, can also be provided to the first physical callback list for use.

[0046] When receiving an instruction to delete all flow tables of the first physical function, the flow tables in each storage block in the first physical callback list can be deleted. After the deletion is completed, all shared blocks allocated to the first physical callback list can be returned to the shared pool. Since when the instruction to delete all flow tables of the first physical function is received, all storage blocks in the first physical callback list can be directly deleted, a large number of operations for searching the flow table of the first physical function can be reduced.

[0047] In order to ensure the robustness of data transmission, the first physical function and the second physical function can form a binding port. The first physical function corresponds to the first physical callback list, and the second physical function corresponds to the second physical callback list. The first physical callback list and the second physical callback list belong to multiple physical callback lists.

[0048] When the virtual switch unloads the second flow table to the callback list of the network card, and the ingress port of the second flow table is a binding port, the second flow table can be stored in the first physical callback list, or the second physical callback list. In a specific embodiment, if the number of free storage blocks of the first physical callback list is greater than the number of free storage blocks of the second physical callback list, the network card stores the second flow table in the first physical callback list, and when the second flow table is stored in the first physical callback list, the correspondence between the second flow table and the first physical callback list is stored. If the number of free storage blocks of the second physical callback list is greater than the number of free storage blocks of the first physical callback list, the network card stores the second flow table in the second physical callback list, and when the second flow table is stored in the second physical callback list, the correspondence between the second flow table and the second physical callback list is stored. In the above scheme, for the flow table of the binding port, it can be selected to be stored in a relatively free physical callback list, thereby improving the utilization rate of the physical callback list.

[0049] In the case where the second flow table needs to be deleted, if it is determined that the second flow table is stored in the first physical callback list based on the correspondence between the second flow table and the first physical callback list, the second flow table is deleted from the first physical callback list; if it is determined that the second flow table is stored in the second physical callback list based on the correspondence between the second flow table and the second physical callback list, the second flow table is deleted from the second physical callback list.

[0050] See also Figure 5 , Figure 5 4 is a schematic diagram of a computing device provided by the present application. The computing device 400 includes: one or more processing units 410 , a communication interface 420 and a memory 430 .

[0051] The processing unit 410, the communication interface 420 and the memory 430 are interconnected via a bus 440. Optionally, the computing device 400 may also include an input / output interface 450, which is connected to an input / output device for receiving parameters set by a user, etc. The computing device 400 can be used to implement part or all of the functions of the device embodiment or system embodiment in the above-mentioned embodiment of the present application; the processing unit 410 can also be used to implement part or all of the operation steps of the method embodiment in the above-mentioned embodiment of the present application. For example, the specific implementation of the various operations performed by the computing device 400 can refer to the specific details in the above-mentioned embodiment, such as the processing unit 410 is used to perform part or all of the steps in the above-mentioned method embodiment or part or all of the operations in the above-mentioned method embodiment. For another example, in the embodiment of the present application, the computing device 400 can be used to implement part or all of the functions of one or more components in the above-mentioned device embodiment, and the communication interface 420 can be specifically used for the communication functions necessary to implement the functions of these devices and components, and the processing unit 410 can be specifically used for the processing functions necessary to implement the functions of these devices and components, etc.

[0052] Figure 5 The computing device 400 may include one or more processing units 410, and the multiple processing units 410 may provide processing capabilities in a coordinated manner in a parallel connection manner, a serial connection manner, a serial-parallel connection manner, or any connection manner, or the multiple processing units 410 may constitute a processor sequence or a processor array, or the multiple processing units 410 may be divided into a main processor and an auxiliary processor, or the multiple processing units 410 may have different architectures such as a heterogeneous computing architecture. In addition, Figure 5 The computing device 400 shown in the figure, and the related structural description and functional description are exemplary and non-limiting. In some exemplary embodiments, the computing device 400 may include Figure 5More or fewer components may be shown, or some components may be combined or separated, or may have a different arrangement of components.

[0053] The processing unit 410 may have a variety of specific implementation forms. For example, the processing unit 410 may include a central processing unit (CPU), a graphic processing unit (GPU), a neural-network processing unit (NPU), a tensor processing unit (TPU) or a data processing unit (DPU), etc., and the embodiment of the present application does not specifically limit it. The processing unit 410 may also be a single-core processor or a multi-core processor. The processing unit 410 may be a combination of a CPU and a hardware chip. The above-mentioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD) or a combination thereof. The above-mentioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof. The processing unit 410 may also be implemented using a logic device with built-in processing logic alone, such as an FPGA or a digital signal processor (DSP). The communication interface 420 may be a wired interface or a wireless interface for communicating with other modules or devices, the wired interface may be an Ethernet interface, a local interconnect network (LIN), etc., the wireless interface may be a cellular network interface or a wireless local area network interface, etc. The processing unit 410 may also be equipped with one or more random access memories, and the one or more random access memories are used to store flow table entries.

[0054] The memory 430 may be a non-volatile memory, such as a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The memory 430 may also be a volatile memory, which may be a random access memory (RAM) used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous connection dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). The memory 430 may also be used to store program codes and data, so that the processing unit 410 calls the program codes stored in the memory 430 to execute some or all of the operation steps in the above method embodiment, or to execute the corresponding functions in the above device embodiment. Figure 5 Show more or fewer components, or have different component configurations.

[0055] The bus 440 may be a peripheral component interconnect express (PCIe) bus, an extended industry standard architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL), a cache coherent interconnect for accelerators (CCIX), etc. The bus 440 may be divided into an address bus, a data bus, a control bus, etc. In addition to the data bus, the bus 440 may also include a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity, Figure 5 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0056] The present application also provides a system, which includes multiple computing devices, and the structure of each computing device can refer to the structure of the computing device described above. The functions or operations that can be implemented by the system can refer to the specific implementation steps in the above method embodiment and / or the specific functions described in the above device embodiment, which will not be repeated here.

[0057] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one network site, computer, server or data center to another network site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer, or it can be a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape, etc.), an optical medium (e.g., a DVD, etc.), or a semiconductor medium (e.g., a solid-state hard disk), etc. In the above embodiments, the description of each embodiment has different emphases. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

Claims

1. A flow table unloading system, characterized in that: include: A processor, configured to run a virtual switch, wherein the virtual switch is a switch virtualized based on hardware resources of the processor, and the virtual switch is configured to offload a flow table to a callback list of a network card; A network card, comprising a plurality of physical functions and a shared pool, wherein the shared pool comprises a plurality of shared blocks, a callback list of the network card comprises a plurality of physical callback lists, wherein the plurality of physical callback lists and the plurality of physical functions have a one-to-one correspondence, the physical callback list comprises a plurality of storage blocks, any one of the plurality of shared blocks is a storage block that can be allocated to any one of the physical callback lists, and the physical function only searches for and deletes a flow table entry of the physical function in the corresponding physical callback list; The multiple physical callback lists include a first physical callback list and a second physical callback list, the first physical function corresponds to the first physical callback list, the second physical function corresponds to the second physical callback list, the first physical function and the second physical function belong to the multiple physical functions, and the first physical function and the second physical function constitute a binding port; The virtual switch is used to unload the second flow table to the callback list of the network card, wherein the ingress port of the second flow table is the binding port; The network card is further configured to store the second flow table in the first physical callback list when the number of free storage blocks in the first physical callback list is greater than the number of free storage blocks in the second physical callback list; The network card is further configured to store the second flow table in the second physical callback list when the number of free storage blocks in the second physical callback list is greater than the number of free storage blocks in the first physical callback list; The network card is also used to store the correspondence between the second flow table and the first physical callback list when the second flow table is stored in the first physical callback list; and to store the correspondence between the second flow table and the second physical callback list when the second flow table is stored in the second physical callback list.

2. The system according to claim 1, characterized in that The multiple physical callback lists include a first physical callback list, a first physical function corresponds to the first physical callback list, and the first physical function belongs to the multiple physical functions, The virtual switch is used to offload a first flow table to a callback list of the network card, wherein an ingress port of the first flow table is the first physical function; The network card is used for storing the first flow table in a free storage block of the first physical callback list when there is a free storage block in the first physical callback list; and for allocating a first shared block to the first physical callback list and storing the first flow table in a first shared block allocated to the first physical callback list when there is no free storage block in the first physical callback list.

3. The system according to claim 2, characterized in that The network card is used for searching the first flow table in the first physical callback list when receiving an instruction to delete the first flow table, deleting the first flow table when the first flow table is found, and returning the first shared block to the shared pool.

4. The system according to any one of claims 1 to 3, characterized in that: The network card is further configured to delete the flow table in each storage block in the first physical callback list when receiving an instruction to delete all flow tables of the first physical function.

5. The system according to claim 1, characterized in that The network card is also used to delete the second flow table from the first physical callback list when a deletion command of the second flow table is received and the second flow table is stored in the first physical callback list; and to delete the second flow table from the second physical callback list when a deletion command of the second flow table is received and the second flow table is stored in the second physical callback list.

6. The system according to any one of claims 1 to 3, characterized in that: The number of shared blocks in the shared pool is greater than the number of storage blocks in any one physical callback list.

7. A computing device, characterized in that It comprises a flow table unloading system and a storage unit, the flow table unloading system and the storage unit can communicate with each other, and the flow table unloading system is a system as described in any one of claims 1-6.

8. A computing device cluster, characterized in that: It comprises a flow table unloading system and a storage unit, the flow table unloading system and the storage unit can communicate with each other, and the flow table unloading system is a system as described in any one of claims 1-6.

Images