Data processing method and device, program product and storage medium

Abstract

The invention provides a data processing method and device, a program product and a storage medium. The method comprises the steps that first information of a first software flow table is obtained, a first stub object corresponding to the first software flow table is created according to the first information, the first software flow table is unloaded into a first hardware flow table, and the first stub object is maintained in a virtual switch in an SoC in a DPU; after the first stub object is created, the first software flow table is written into a first file, and the first file is a file in an SoC file system in a DPU.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a data processing method, device, program product and storage medium. Background Technology

[0002] In the cloud computing field, virtual switches are a crucial component of the network infrastructure within current cloud data centers. The data path of a virtual switch typically consumes significant CPU and memory resources during packet forwarding. As data volumes increase, tenants demand higher data forwarding performance, and the performance bottleneck of the software-based data path becomes increasingly apparent. To reduce resource consumption and overcome performance bottlenecks, the data path of the virtual switch is offloaded to an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA), a technique known as hardware offloading. For packets that have triggered and completed the hardware offloading process, the corresponding software flow table and hardware flow table have different appearances but the underlying logic is the same. At any given time, the software flow table exists within the virtual switch data path, while the hardware flow table exists in the hardware flow table cache module. Since data packets that have triggered and completed the hardware offloading process will be prioritized for rapid hardware processing after flowing into the Data Processing Unit (DPU), and will not flow into the virtual switch within the System on Chip (SOC), under this technical solution, completely storing the flow characteristics and action indication information of the software flow table in the virtual switch is a waste of DPU SoC memory resources and will limit the amount of business that the DPU can handle. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a data processing method, apparatus, program product, and storage medium. These can improve the efficiency of DPU resource utilization.

[0004] This application provides a data processing method, the method comprising: Obtain the first information of the first software flow table, and create the first stub object corresponding to the first software flow table based on the first information. The first software flow table is unloaded into the first hardware flow table, and the first stub object is maintained in the virtual switch in the SoC of the DPU. After creating the first stub object, the first software flow table is written to the first file, which is a file in the SoC file system of the DPU.

[0005] This application provides a DPU, which includes: a SoC and hardware; the SoC includes a virtual switch and a software flow table transfer medium; wherein... The hardware is used to store hardware flow tables, which are software flow tables that have been offloaded from the virtual switch. The virtual switch is used to obtain first information of the first software flow table, and create a first stub object corresponding to the first software flow table based on the first information. The first software flow table is unloaded into a first hardware flow table, and the first stub object is maintained in the virtual switch in the SoC of the DPU. After creating the first stub object, the first software flow table is written to a first file, which is a file in the SoC file system of the DPU.

[0006] The data processing apparatus provided in this application includes a processor and a memory, wherein the memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to perform the above-described data processing method.

[0007] This application provides a computer program product, comprising: a computer program that, when executed by a processor, implements the above-described data processing method.

[0008] The computer-readable storage medium provided in this application is used to store a computer program that causes a computer to perform the above-described data processing method.

[0009] In the technical solution of this application, first information of a first software flow table is obtained, and a first stub object corresponding to the first software flow table is created based on the first information. The first software flow table is unloaded into a first hardware flow table, and the first stub object is maintained in the virtual switch within the SoC of the DPU. After creating the first stub object, the first software flow table is written to a first file, which is a file in the SoC file system of the DPU. Thus, by creating the first stub object of the first software flow table and writing the first software flow table to the first file, the transfer of the first software flow table is achieved, improving the resource utilization efficiency of the DPU. Attached Figure Description

[0010] The accompanying drawings, which are provided to further illustrate this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application.

[0011] Figure 1 This is a schematic diagram of hardware unloading provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the data processing method provided in an embodiment of this application; Figure 3 This is a schematic diagram of a DPU provided in an embodiment of this application; Figure 4 This is a schematic diagram of the overall architecture of the data processing method provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structural composition of the data processing apparatus provided in the embodiments of this application; Figure 6 This is a schematic structural diagram of a data processing device provided in an embodiment of this application; Figure 7 This is a schematic structural diagram of the chip according to an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0013] In the following description, the term "some embodiments" refers to a subset of all possible embodiments. However, it is understood that "some embodiments" can be the same or different subsets of all possible embodiments and can be combined with each other without conflict. It should also be noted that the terms "first," "second," and "third" used in the embodiments of this application are only used to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first," "second," and "third" can be interchanged in a specific order or sequence where permissible, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein. The term "and / or" in this document is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship. It should also be understood that the "instruction" mentioned in the embodiments of this application can be a direct instruction, an indirect instruction, or an indication of an association relationship. For example, A instructing B can mean that A directly instructs B, for example, B can obtain information through A; it can also mean that A indirectly instructs B, for example, A instructs C, and B can obtain information through C; it can also mean that there is an association between A and B. It should also be understood that the term "correspondence" mentioned in the embodiments of this application can mean that there is a direct or indirect correspondence between the two, or that there is an association between the two, or that there is an instruction and being instructed, configuration and being configured, etc.

[0014] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0015] In the cloud computing field, virtual switches are a crucial component of the network infrastructure within current cloud data centers. The data paths of virtual switches typically consume significant CPU and memory resources during packet forwarding. As data volumes increase, tenants demand higher data forwarding performance, and the performance bottlenecks of software-based data paths become increasingly apparent. To reduce resource consumption and overcome performance bottlenecks, the data paths of virtual switches are offloaded to ASICs or FPGAs—a technique known as hardware offloading—which has emerged.

[0016] Hardware offloading technology uses a Data Processing Unit (DPU) as its carrier, with software and hardware working together. For data packets flowing into the DPU, the DPU's hardware chip (ASIC or FPGA, hereinafter referred to as hardware) first searches its own flow table cache module based on the packet's header characteristics. For packets where a matching flow table entry can be found in the flow table cache module, the hardware only needs to process the packet according to the action instructions in the flow table entry. For packets where a matching flow table entry cannot be found in the flow table cache module, the hardware needs to send the packet to the DPU's System-on-a-Chip (SoC), where a virtual switch within the SoC performs further processing. The virtual switch extracts the packet's header characteristics into flow characteristics, abstracts the proposed processing method for the packet into action instructions, and combines the flow characteristics and action instructions into a software flow table. Subsequently, the virtual switch processes the packet according to the action instructions in the software flow table (e.g., forwarding, NAT), and simultaneously synchronizes the software flow table to the hardware's flow table cache module to form a hardware flow table, thus completing one instance of hardware offloading for the data packet. Figure 1 This is a schematic diagram of hardware unloading provided in an embodiment of this application, such as... Figure 1 As shown, in the hardware offloading model, for a data stream, only the first data packet in the stream (hereinafter referred to as the first packet) needs to be sent to the SoC and trigger hardware offloading. Subsequent data packets can be directly processed by the DPU hardware because they are matched with the hardware flow table, thus achieving high-speed forwarding of data packets.

[0017] For data packets that have triggered and completed the hardware offload process, the corresponding software flow tables and hardware flow tables have different appearances, but the underlying logic is the same. At the same time, the software flow table will exist in the virtual switch data path, and the hardware flow table will exist in the hardware flow table cache module. Since data packets that have triggered and completed the hardware offload process will be processed quickly by the hardware after flowing into the DPU and will not flow into the virtual switch within the SoC, the software flow tables that have completed offloading will no longer participate in the data packet processing process, but will only be used to assist in completing the flow statistics and aging cleanup tasks of the flow tables.

[0018] Under this technical solution, completely storing the flow characteristics and action indication information of the software flow table in the virtual switch is a waste of DPU SoC memory resources and will limit the amount of business that the DPU can handle. For example, in an application scenario with millions of connections, the flow table related to 1m connections will have 2m entries (after merging), requiring gigabytes of SoC memory resources. In SoCs with relatively limited memory resources, the existing technical solution will directly limit the upper limit of the number of connections that the DPU can concurrently maintain.

[0019] In one embodiment, a message transmission method and related apparatus applied to a DPU are provided, comprising: receiving a first data packet via a hardware module and determining the service type of the first data packet; if it is determined that there is no flow table entry matching the first data packet in the flow table stored in the hardware module, sending the first data packet and its service type to a software module; obtaining a first-format flow table corresponding to the first data packet via the software module, and determining a valid matching field of the first data packet based on its service type; converting the first-format flow table into a second-format flow table via the software module based on the valid matching field of the first data packet; transmitting the second-format flow table corresponding to the first data packet to the hardware module via the software module; and transmitting the data stream to which the first data packet belongs via the hardware module based on the second-format flow table corresponding to the first data packet. Implementing this solution can save hardware storage space. Although this solution is a standard hardware offloading technology, achieving fast data packet processing according to the software-defined, hardware-accelerated approach, it maintains all software flow table information within the SoC, resulting in low SoC memory utilization.

[0020] In another embodiment, a message processing method, apparatus, electronic device, and storage medium are disclosed. The method includes: receiving message data through a dedicated data processor; matching the message data with various merge flow tables in the dedicated data processor; if a merge flow table matching the message data exists, processing the message data using the matching merge flow table; if no merge flow table matching the message data exists, transmitting the message data to a main computing device; and using the main computing device, processing the message data using multiple message processing rules matching the message data and generating a merge flow table for the message data, and offloading the merge flow table to the dedicated data processor. Therefore, by generating a merge flow table for message data, this application can support the simultaneous offloading of multiple message processing rules to the hardware, enabling the hardware to support the direct processing of most message data and improving message data processing efficiency. Although this solution uses the idea of ​​merging flow tables to complete hardware offloading, merging multiple software flow tables into a single hardware flow table before completing the offloading, this solution can effectively save DPU hardware flow table cache module resources, but it also ignores the optimization of the SoC side memory usage method. In another approach, a service mesh data plane acceleration method, apparatus, and readable storage medium are provided. The method includes: offloading a scalable packet filter (eBPF) program providing forwarding functionality to a data processing unit (DPU); attaching the eBPF program to a fast data path (XDP) / traffic classifier (TC) hook; and using the XDP / TC hook to forward packets between service mesh data plane components. This method, apparatus, and readable storage medium address the problem in existing technologies where, during service mesh function call chains, traffic in the function chain must pass through a message broker / front-end broker each time it passes through the kernel, leading to overload and degraded data plane performance due to additional data copying, context switching, and interrupts. While this approach optimizes the offloading process of software flow tables to hardware flow tables through the XDP / TC hook, it still fails to improve the efficiency of SoC memory utilization.

[0021] Existing hardware offloading schemes offload flow tables from the virtual switch in the SoC to the DPU hardware for execution, leveraging the DPU hardware to accelerate packet forwarding. However, existing solutions manage software flow tables somewhat crudely. For software flow tables that have completed the offloading process, since they no longer participate in packet processing, there is no need to maintain their full information in the virtual switch. This reduces the efficiency of DPU SoC memory usage and limits the workload the DPU can handle. Therefore, improving DPU resource utilization efficiency becomes a crucial issue. To address this, the following technical solution, as proposed in this application, is presented.

[0022] To facilitate understanding of the technical solutions of the embodiments of this application, the technical solutions of this application are described in detail below through specific embodiments. The above-mentioned related technologies are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. The embodiments of this application include at least some of the following contents.

[0023] It should be noted that the embodiments of this application are illustrated using the first software flow table as an example. In actual applications, it can be applied to one or more software flow tables at the same time.

[0024] Figure 2 This is a flowchart illustrating the data processing method provided in an embodiment of this application, as shown below. Figure 2 As shown, the data processing method includes the following steps: Step 201: Obtain the first information of the first software flow table, and create the first stub object corresponding to the first software flow table based on the first information.

[0025] Step 202: After creating the first stub object, write the first software flow table into the first file.

[0026] The first software flow table is unloaded into a first hardware flow table, the first stub object is maintained in the virtual switch of the SoC in the DPU, and the first file is a file in the SoC file system in the DPU.

[0027] In some implementations, in the hardware offloading technique, the software flow table that has been offloaded into a hardware flow table no longer participates in the data packet processing flow. It is only used to assist in completing the flow statistics and aging cleanup tasks of the hardware flow table. Therefore, the first software flow table that has been offloaded is transferred to a first file. Only the basic information of the first software flow table needs to be maintained in memory. That is, for the first software flow table that has been offloaded into a first hardware flow table, the first information of the first software flow table is obtained, which is equivalent to the aforementioned basic information. Based on the first information, a first stub object corresponding to the first software flow table is created and maintained in the virtual switch in the SoC in the DPU. After creating the first stub object, the first software flow table is written to the first file, which is a file in the SoC file system in the DPU. In this way, by creating the first stub object of the first software flow table and writing the first software flow table to the first file, the transfer of the first software flow table is realized, which improves the resource utilization efficiency of the DPU.

[0028] In some implementations, the first information includes one or more of the following: a first identifier of a first software flow table, the number of packets that hit the first software flow table, the time interval information for hitting the first software flow table, and a second identifier of a first hardware flow table.

[0029] In some implementations, the ufid identifier of the first software flow table to be transferred, i.e. the aforementioned first identifier, the total number of packets that hit the first software flow table, and the time interval used since the last hit of the first software flow table are extracted. At the same time, the handle_id of the first hardware flow table corresponding to the first software flow table to be transferred, i.e. the aforementioned second identifier, is extracted. The handle_id is the unique identifier of the first hardware flow table in the hardware flow table cache module.

[0030] Understandably, at this point, the first software flow table has been successfully synchronized to the hardware, and the corresponding hardware flow table is the first hardware flow table. "used" is the time interval between the moment when the first information of the first software flow table was extracted and the moment when the first software flow table was last hit.

[0031] In some implementations, writing the first software flow table into a first file includes: organizing the first software flow table to be transferred into a string of a first format according to the data structure of the first software flow table, and writing the string into the first file, wherein the first format corresponds to the first software flow table.

[0032] In some implementations, after creating the first stub object corresponding to the first software flow table, the first software flow table is written to the first file. Specifically, according to the data structure of the first software flow table, the first software flow table to be transferred is organized into a string of a first format and written to the first file, wherein the first format corresponds to the first software flow table.

[0033] In some implementations, the string in the first format includes first information of the first software flow table and some information of the string itself. The specific format of the string is related to the corresponding software flow table, and this application does not specifically limit it.

[0034] It is understandable that different software flow tables correspond to strings in different formats; that is, the first format corresponds to the first software flow table.

[0035] In some implementations, the location where the software flow table is transferred can also be called the software flow table transfer medium. The software flow table transfer medium is a db file in the DPU SoC file system, also known as the first file. The db file can be read and written by the virtual switch process. When the virtual switch needs to transfer the software flow table, it writes the software flow table to be transferred into the db file.

[0036] In some implementations, when the virtual switch needs to age out and clean up the hardware flow tables, it also erases the transferred software flow tables from the db file.

[0037] In some implementations, information such as the ufid identifier, packets (total number of packets hitting the first software flow table), and used (time interval since the last hit of the first software flow table) of the first software flow table to be transferred are extracted. The handle_id information (unique identifier of the first hardware flow table in the hardware flow table cache module) of the first hardware flow table corresponding to the first software flow table is extracted. The extracted information is used to construct a software flow table stub object, i.e., the first stub object, and maintained in the virtual switch. According to the software flow table data structure, the first software flow table to be transferred is organized into a string with a fixed format and then written into the software flow table transfer medium, i.e., written into the first file.

[0038] In some implementations, after the first software flow table is written to the first file, the method further includes: deleting the cached first software flow table in the data path of the virtual switch.

[0039] It is understandable that at this point, the virtual switch data path only retains the first stub object of the first software flow table. If multiple software flow tables are transferred, then the multiple stub objects corresponding to the multiple software flow tables are retained. It should also be understood that if there are multiple ununloaded software flow tables, then the virtual switch data path includes the stub objects corresponding to the multiple transferred software flow tables and the multiple ununloaded software flow tables. In this case, the multiple ununloaded software flow tables are all full software flow tables.

[0040] In some implementations, the method further includes: obtaining flow statistics information for performing flow statistics on the first hardware flow table, and writing the flow statistics information into a first stub object.

[0041] In some implementations, for the unloaded software flow table, it is used to assist in completing the flow statistics task of the hardware flow table. Therefore, for the first software flow table that has been transferred, the flow statistics information of the first hardware flow table corresponding to the first software flow table is obtained and the flow statistics information is written into the first stub object.

[0042] In some implementations, the flow statistics information includes the number of times the first hardware flow table is hit and the time interval information between the hits on the first hardware flow table. Here, the time interval information between the hits on the first hardware flow table is the time interval between the moment when flow statistics are performed on the first hardware flow table and the moment when the first hardware flow table was last hit.

[0043] In some implementations, during the flow statistics process of the flow table, after the first software flow table is successfully unloaded, the virtual switch no longer attempts to write the flow statistics information synchronized from the hardware into the software flow table, but instead writes the flow statistics information into the packets and used data members of the software flow table stub object.

[0044] In some implementations, the frequency information of the first hardware flow table in the flow statistics is written into the first stub object to update the original packets in the first stub object based on the flow statistics information, and the time interval information is written into the first stub object to update the original used based on the flow statistics information.

[0045] It is understood that the timing of writing the flow statistics information of the first hardware flow table to the first stub object can be determined according to the actual situation. It can be written immediately after the flow statistics are written, or it can be written after a set time. This application does not make a specific limitation on this. It should also be understood that in the first information obtained, used is a fixed value, and this value will change after the flow statistics information is written to the first stub object.

[0046] In some implementations, the method further includes: determining whether to clean the first software flow table based on flow statistics.

[0047] In some implementations, during the aging and cleaning of flow tables, it is determined whether to clean the first software flow table based on flow statistics.

[0048] In some implementations, if the time interval information in the flow statistics is greater than a first threshold, that is, if no data packet hits the first hardware flow table for a long time, it is determined that the first software flow table needs to be cleaned.

[0049] In some implementations, cleaning up the first software flow table includes deleting the first software flow table from the first file.

[0050] In some implementations, the method further includes: when it is determined that the first software flow table should be cleaned, the following processes are executed sequentially: locating and erasing the first hardware flow table corresponding to the first software flow table according to the second identifier; locating and erasing the first software flow table in the first file according to the first identifier; and releasing the first stub object.

[0051] In some implementations, during the aging and cleaning process of flow tables, when the virtual switch determines that the first software flow table needs to be aged and cleaned based on the flow statistics information in the first stub object corresponding to the first software flow table, the following steps are executed sequentially: based on the handle_id information in the first software flow table stub object, locate the corresponding first hardware flow table in the hardware flow table cache module and erase the corresponding first hardware flow table in the hardware flow table cache module; based on the ufid information in the first stub object corresponding to the first software flow table, locate the corresponding first software flow table that has been transferred in the first file and erase the corresponding first software flow table that has been transferred in the first file; release the first stub object corresponding to the first software flow table, thus closing the flow table aging and cleaning process.

[0052] Understandably, if it is determined that multiple software flow tables need to be cleaned, the above process should be performed on each of the multiple software flow tables separately.

[0053] The technical solution of this application embodiment obtains first information of a first software flow table, and creates a first stub object corresponding to the first software flow table based on the first information. The first software flow table is unloaded into a first hardware flow table, and the first stub object is maintained in the virtual switch within the SoC in the DPU. After creating the first stub object, the first software flow table is written to a first file, which is a file in the SoC file system of the DPU. Thus, by creating the first stub object of the first software flow table and writing the first software flow table to the first file, the first software flow table is transferred, improving the efficiency of DPU resource utilization.

[0054] Based on the foregoing embodiments, Figure 3 This is a schematic diagram of a DPU provided in an embodiment of this application, such as... Figure 3 As shown, the DPU300 includes: SoC301 and hardware 302; the SoC301 includes a virtual switch 3011 and a software flow table transfer medium 3012; wherein, The hardware 302 is used to store hardware flow tables, which are software flow tables that are offloaded from the virtual switch 3011. The virtual switch 3011 is used to obtain the first information of the first software flow table, and create a first stub object corresponding to the first software flow table based on the first information. The first software flow table is unloaded into a first hardware flow table, and the first stub object is maintained in the virtual switch 3011 in the SoC 301 of the DPU 300. After creating the first stub object, the first software flow table is written to a first file, which is a file in the SoC file system of the DPU 300.

[0055] Among them, the software flow table transfer medium 3012 is a file in the SoC301 file system in the DPU300.

[0056] The first information includes one or more of the following: the first identifier of the first software flow table, the number of packets that hit the first software flow table, the time interval information of hitting the first software flow table, and the second identifier of the first hardware flow table.

[0057] The virtual switch 3011 is used to organize the first software flow table to be transferred into a string of a first format according to the data structure of the first software flow table, and write the string into the first file, wherein the first format corresponds to the first software flow table.

[0058] The virtual switch 3011 is used to obtain flow statistics information for flow statistics of the first hardware flow table and write the flow statistics information into the first stub object.

[0059] The flow statistics include the number of times the first hardware flow table is hit and the time interval between the hits on the first hardware flow table.

[0060] The virtual switch 3011 is used to determine whether to clean up the first software flow table based on flow statistics information. When it is determined to clean up the first software flow table, the following processes are executed in sequence: according to the second identifier, locate and erase the first hardware flow table corresponding to the first software flow table in the hardware 302; according to the first identifier, locate and erase the first software flow table in the first file in the software flow table transfer medium 3012; release the first stub object in the virtual switch 3011.

[0061] Based on the foregoing embodiments, the data processing method provided by the embodiments of this application will be further described.

[0062] Existing hardware offloading solutions offload flow tables from the virtual switch in the SoC to the DPU hardware for execution, leveraging the DPU hardware to accelerate packet forwarding. However, existing solutions manage software flow tables somewhat crudely. For software flow tables that have completed the offloading process, since they no longer participate in packet processing, there is no need to maintain their full information in the virtual switch. This reduces the efficiency of DPU SoC memory usage and limits the workload that the DPU can handle.

[0063] The aforementioned existing solutions all focus on hardware offloading technology. However, the second existing solution focuses on improving the efficiency of DPU resource utilization to increase the workload that the DPU can handle. This aims to improve the utilization efficiency of DPU hardware storage resources by merging multiple software flow tables into a single hardware flow table before offloading. This solution uses flow table merging to complete hardware offloading, effectively saving DPU hardware flow table cache module resources, but it also neglects the optimization of SoC-side memory usage. Based on the shortcomings of existing solutions, this application's embodiments design a mechanism and storage medium to transfer the offloaded software flow tables to the SoC hard drive. Without affecting DPU network performance, this improves the utilization efficiency of SoC memory, enabling a DPU with the same memory specifications to handle a higher volume of services. In other words, this solution aims to improve the utilization efficiency of DPU SoC memory resources by transferring the offloaded software flow tables.

[0064] In hardware offloading technology, software flow tables that have been offloaded into hardware flow tables no longer participate in the data packet processing flow. They are only used to assist in completing flow statistics and aging cleanup tasks for the hardware flow tables. Maintaining the full information of the software flow tables in memory is a waste of memory resources and does not help improve DPU network performance. In order to improve the utilization efficiency of DPU SoC memory resources and increase the service load that the DPU can handle without affecting DPU network performance, this application embodiment designs a mechanism and a storage medium. Figure 4 This is a schematic diagram of the overall architecture of the data processing method provided in the embodiments of this application, as shown below. Figure 4 As shown, the data path in the virtual switch includes multiple full software flow tables that are not unloaded and multiple software flow table stubs corresponding to the unloaded full software flow tables. The unloaded full software flow tables are transferred to the software flow table transfer medium (SoC file system). The hardware flow tables in the hardware, the unloaded full software flow tables in the software flow table transfer medium, and the software flow table stubs in the data path of the virtual switch correspond one-to-one. It should be noted that the software flow table stubs (unloaded) in the data path of the virtual switch are the result of hardware unloading of their corresponding full software flow tables. The full software flow tables here are the aforementioned software flow tables, distinguished from the software flow table stubs. The technical solution of this application embodiment is described in detail below: 1. Software flow table transfer medium The software flow table storage medium is a db file in the DPU SoC file system. The db file can be read and written by the virtual switch process. When the virtual switch needs to transfer the software flow table, it writes the software flow table to be transferred into the db file. When the virtual switch needs to age out and clean up the hardware flow table, it also erases the transferred software flow table from the db file.

[0065] The software flow table storage medium does not restrict the format and content of the software flow tables that are written.

[0066] 2. Software flow table transfer mechanism The software flow table transfer mechanism can be summarized as follows: the software flow table that has been uninstalled is transferred to the software flow table transfer medium, and only the basic information of the software flow table is maintained in memory to assist in the flow statistics and aging cleanup tasks of software and hardware flow tables.

[0067] The software flow table transfer mechanism is a modification and enhancement of the hardware offloading technology. It uses virtual switches and software flow table transfer media as carriers and is applied to the three core hardware offloading processes under the hardware offloading scheme: software flow table offloading to hardware, flow statistics of flow tables, and aging and cleaning of flow tables.

[0068] In the process of offloading software flow tables to hardware, after the software flow tables are successfully synchronized to the hardware, the virtual switch transfers the software flow tables to the software flow table transfer medium. After the transfer is successful, the hardware offloading process is closed. The specific details of the software flow table transfer process are as follows: Extract the ufid identifier, packets (total number of packets hitting the flow table), and used (time interval since the last hit on the flow table) information from the software flow table to be transferred. Extract the handle_id (unique identifier of the hardware flow table in the hardware flow table cache module) information from the corresponding hardware flow table. Construct the extracted information into a software flow table stub object (equivalent to the aforementioned first stub object) and maintain it in the virtual switch. Here, used is the time interval between the time when this information is extracted and the time of the last hit on the software flow table. It can be understood that used corresponds to a fixed value, which is updated when flow statistics information is written. This information is the aforementioned basic information.

[0069] After creating the software flow table stub object, the software flow table to be transferred is organized into a fixed-format string according to the software flow table data structure, and then the string is written into the software flow table transfer medium. Here, the fixed format corresponds to the software flow table; that is, different software flow tables have different fixed formats. The fixed-format string includes the basic information of the software flow table and the information of the flow itself, which is specifically related to the software flow table.

[0070] After the string is written to the software flow table transfer medium, delete the full cached software flow table in the data path of the virtual switch.

[0071] In the process of performing flow statistics on flow tables, after a software flow table is successfully unloaded, the virtual switch no longer attempts to write the flow statistics information synchronized from the hardware into the software flow table. Instead, it writes the flow statistics information into the packets and used data members of the software flow table stub object. Here, the flow statistics information includes the number of times the corresponding hardware flow table is hit and the time interval since the last hit of that flow table. It can be understood that writing the number of times the corresponding hardware flow table is hit into the software flow table stub object is to update the original packets, that is, to add the current number of statistics to the original packets, and writing the time interval since the last hit of that flow table into the software flow table stub object is to update the original used. In this embodiment, successful software flow table unloading includes the hardware unloading process, the process of constructing the software flow table stub object corresponding to the software flow table, the process of transferring the software flow table to the software flow table transfer medium, and the process of deleting the cached full software flow table in the data path of the virtual switch.

[0072] In the process of aging and cleaning up flow tables, it is determined whether the software flow table needs to be cleaned based on the time interval information in the flow statistics. When the time interval information is greater than the first threshold, that is, no data packets have hit the hardware flow table for a long time, it is determined that the software flow table corresponding to the hardware flow table needs to be cleaned.

[0073] When a virtual switch determines that a flow table needs to be aged out and cleaned up based on the flow statistics information in the software flow table stub object, the following process must be executed in sequence: Based on the handle_id information in the software flow table stub object, locate and erase the corresponding hardware flow table in the hardware flow table cache module; Based on the ufid information in the software flow table stub object, locate and erase the corresponding transferred software flow table in the software flow table transfer medium; Release the software flow table stub object to close the flow table aging and cleanup process.

[0074] Based on the software flow table dumping mechanism of this application embodiment, the main body of the software flow table is dumped to the SoC hard disk resources, while only lightweight software flow table stub objects are retained in the SoC memory, significantly reducing the SoC memory resource usage. Furthermore, the software flow table dumping mechanism proposed in this application embodiment only applies to software flow tables that have been offloaded and are no longer involved in traffic processing; therefore, the software flow table dumping mechanism will not affect DPU network performance. This application embodiment is an enhancement of existing hardware offload technology, does not change the core process of existing hardware offload schemes, and has good forward compatibility.

[0075] This application proposes a software flow table transfer mechanism and its auxiliary storage medium. By transferring software flow tables that have completed the hardware offloading process to the DPU SoC file system, the virtual switch's occupation of DPU SoC memory resources is reduced without affecting DPU network performance, enabling DPUs with the same memory specifications to handle higher volumes of service traffic. To avoid affecting the hardware offloading technology, this application uses software flow table stub objects for the flow statistics and aging cleanup process of the flow tables. The software flow table stub objects are maintained in the virtual switch data path and only contain data such as software flow table identifiers, hardware flow table identifiers, and flow table flow statistics information, using a lightweight data structure to support the logical closed loop of the flow statistics and aging cleanup process.

[0076] This application embodiment reduces the occupation of DPU SoC memory resources by transferring the unloaded software flow tables. In the technical solution of merging software flow tables and then unloading them to the hardware flow table cache module, this application embodiment one can be applied to transfer the intermediate data structure used by merging software flow tables, while optimizing the utilization efficiency of software and hardware storage resources.

[0077] This application proposes a method for managing DPU software flow tables, which reduces the occupation of DPU SoC memory resources by transferring the unloaded software flow tables. This method does not affect the core capabilities of the hardware offloading technology solution. Without reducing DPU network performance, it enables DPUs with the same memory specifications to handle higher volumes of service traffic, helping to build a more efficient cloud computing IaaS layer data plane, and has good market application scenarios. The scheme described in this application, which transfers the unloaded software flow tables from the DPU to the DPU SoC file system to optimize DPU SoC memory usage efficiency, can increase the number of concurrent connections and other service volumes supported by bare-metal servers equipped with DPUs without expanding DPU SoC memory specifications or sacrificing DPU network performance.

[0078] Figure 5 This is a schematic diagram of the structural composition of the data processing device provided in the embodiments of this application, as shown below. Figure 5 As shown, the data processing device includes: Acquisition unit 501 is used to acquire the first information of the first software flow table; Processing unit 502 is configured to create a first stub object corresponding to the first software flow table based on the first information; after creating the first stub object, write the first software flow table into a first file; Specifically, the first software flow table is unloaded into a first hardware flow table, the first stub object is maintained in the virtual switch of the DPUSoC, and the first file is a file in the DPU SoC file system.

[0079] In some implementations, the first information includes one or more of the following: a first identifier of the first software flow table, the number of packets that hit the first software flow table, the time interval information for hitting the first software flow table, and a second identifier of the first hardware flow table.

[0080] In some embodiments, the processing unit 502 is configured to organize the first software flow table to be transferred into a string of a first format according to the data structure of the first software flow table, and write the string into the first file, wherein the first format corresponds to the first software flow table.

[0081] In some implementations, the acquisition unit 501 is used to acquire flow statistics information for performing flow statistics on the first hardware flow table; the processing unit 502 is used to write the flow statistics information into the first stub object.

[0082] In some implementations, the flow statistics include the number of times the first hardware flow table is hit and the time interval between the hits on the first hardware flow table.

[0083] In some implementations, the processing unit 502 is configured to determine whether to clean up the first software flow table based on the flow statistics information; when it is determined to clean up the first software flow table, the following processes are executed sequentially: locating and erasing the first hardware flow table corresponding to the first software flow table based on the second identifier; locating and erasing the first software flow table in the first file based on the first identifier; and releasing the first stub object.

[0084] Those skilled in the art should understand that Figure 5 The functions of each unit in the data processing device shown can be understood by referring to the relevant description of the aforementioned method. Figure 5 The functions of each unit in the data processing device shown can be implemented by a program running on a processor or by specific logic circuits.

[0085] Figure 6 This is a schematic structural diagram of a data processing device 600 provided in an embodiment of this application. Figure 6 The data processing device 600 shown includes a processor 610, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0086] Optionally, such as Figure 6 As shown, the data processing device 600 may further include a memory 620. The processor 610 can retrieve and run computer programs from the memory 620 to implement the methods described in the embodiments of this application.

[0087] The memory 620 can be a separate device independent of the processor 610, or it can be integrated into the processor 610.

[0088] Optionally, such as Figure 6 As shown, the data processing device 600 may also include a transceiver 630, which the processor 610 can control to communicate with other devices. Specifically, it can send information or data to other devices or receive information or data sent by other devices.

[0089] The transceiver 630 may include a transmitter and a receiver. The transceiver 630 may further include antennas, and the number of antennas may be one or more.

[0090] The data processing device 600 can implement the corresponding processes implemented by the data processing apparatus in the various methods of the embodiments of this application, which will not be described in detail here for the sake of brevity.

[0091] Figure 7 This is a schematic structural diagram of the chip according to an embodiment of this application. Figure 7The chip 700 shown includes a processor 710, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0092] Optionally, such as Figure 7 As shown, chip 700 may further include memory 720. Processor 710 can retrieve and run computer programs from memory 720 to implement the methods described in this embodiment.

[0093] The memory 720 can be a separate device independent of the processor 710, or it can be integrated into the processor 710.

[0094] Optionally, the chip 700 may also include an input interface 730. The processor 710 can control the input interface 730 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips.

[0095] Optionally, the chip 700 may also include an output interface 740. The processor 710 can control the output interface 740 to communicate with other devices or chips, specifically, to output information or data to other devices or chips.

[0096] This chip can implement the corresponding processes implemented by the data processing device in the various methods of the embodiments of this application, which will not be described in detail here for the sake of brevity.

[0097] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0098] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0099] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is 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 DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0100] It should be understood that the above-described memory is exemplary and not a limiting description. For example, the memory in the embodiments of this application may also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. That is to say, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0101] This application also provides a computer program product, including a computer program.

[0102] When executed by a processor, the computer program implements the corresponding processes implemented by the data processing device in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0103] This application also provides a computer-readable storage medium for storing computer programs.

[0104] The computer program causes the computer to execute the corresponding processes implemented by the data processing device in the various methods of the embodiments of this application, which will not be described in detail here for the sake of brevity.

[0105] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0106] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0107] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0108] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0109] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0110] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0111] The preferred embodiments of this application have been described in detail above with reference to the accompanying drawings. However, this application is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this application, various simple modifications can be made to the technical solutions of this application, and these simple modifications all fall within the protection scope of this application. For example, the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, this application will not describe the various possible combinations separately. Furthermore, various different embodiments of this application can also be arbitrarily combined, as long as they do not violate the spirit of this application, they should also be considered as the content disclosed in this application. Moreover, without conflict, the various embodiments and / or the technical features in the various embodiments described in this application can be arbitrarily combined with the prior art, and the resulting technical solutions should also fall within the protection scope of this application.

[0112] It should be understood that in the various method embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0113] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A data processing method, characterized in that, The method includes: Obtain the first information of the first software flow table, and create a first stub object corresponding to the first software flow table based on the first information. The first software flow table is unloaded into a first hardware flow table, and the first stub object is maintained in the virtual switch in the SoC of the DPU. After creating the first stub object, the first software flow table is written to the first file, which is a file in the SoC file system of the DPU.

2. The method according to claim 1, characterized in that, The first information includes one or more of the following: The first identifier of the first software flow table, the number of packets that hit the first software flow table, the time interval information of hitting the first software flow table, and the second identifier of the first hardware flow table.

3. The method according to claim 1, characterized in that, The step of writing the first software flow table into the first file includes: According to the data structure of the first software flow table, the first software flow table to be transferred is organized into a string of a first format, and the string is written into the first file, wherein the first format corresponds to the first software flow table.

4. The method according to claim 2, characterized in that, The method further includes: Obtain the flow statistics information for the first hardware flow table and write the flow statistics information into the first stub object.

5. The method according to claim 4, characterized in that, The flow statistics include the number of times the first hardware flow table is hit and the time interval between the hits on the first hardware flow table.

6. The method according to claim 4, characterized in that, The method further includes: Determine whether to clean the first software flow table based on the flow statistics information; When it is determined that the first software flow table should be cleaned, the following process is executed sequentially: Based on the second identifier, locate and erase the first hardware flow table corresponding to the first software flow table; Based on the first identifier, locate and erase the first software flow table in the first file; Release the first stub object.

7. A DPU, characterized in that, The DPU includes: a SoC and hardware; the SoC includes a virtual switch and a software flow table transfer medium; wherein... The hardware is used to store hardware flow tables, which are software flow tables that have been offloaded from the virtual switch. The virtual switch is used to obtain first information of the first software flow table, and create a first stub object corresponding to the first software flow table based on the first information. The first software flow table is unloaded into a first hardware flow table, and the first stub object is maintained in the virtual switch in the SoC of the DPU. After creating the first stub object, the first software flow table is written to a first file, which is a file in the SoC file system of the DPU.

8. A data processing device, characterized in that, include: A processor and a memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the method as described in any one of claims 1 to 6.

9. A computer program product, characterized in that, include: A computer program that, when executed by a processor, implements the method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1 to 6.

Images