Method and system for querying multi-source DPU flow table, DPU cluster and computing device

Abstract

The invention provides a method and system for querying a multi-source DPU flow table, a DPU cluster and computing equipment, and the method comprises the steps: receiving and analyzing a flow table operation statement which comprises a query target field and a filtering condition; converting the flow table operation statement into a structured semantic tree, and extracting the query target field and the filtering condition; according to the query target field, the filtering condition and DPU information obtained from a DPU information base, generating a flow table operation command of the corresponding DPU; respectively issuing the flow table operation commands of the corresponding DPUs to the corresponding DPUs to execute corresponding operations and obtain return values; and unifying the different return values as a final operation result of the logic flow table model field. According to the technical scheme, the problems that heterogeneous DPU flow table query modes are diversified, management is complex, and unified standard interfaces are lacked can be solved, the operation and maintenance efficiency is improved, the use threshold is lowered, and the consistency and intelligence of cross-manufacturer equipment flow table data management are enhanced.

Description

Technical Field

[0001] This invention relates to the field of network chip development technology, specifically to a method, system, DPU cluster, and computing device for querying multi-source DPU flow tables. Background Technology

[0002] With the surge in network bandwidth and virtualization density, traditional processors (CPUs) are becoming overwhelmed in handling tasks such as network protocol stacks (TCP / IP), virtual switching (e.g., OVS), encryption / decryption, and storage protocols (e.g., NVMe-oF), consuming numerous CPU cycles and impacting service performance. Therefore, Data Processing Units (DPUs) have emerged to offload these "infrastructure software" tasks from the CPU to the DPU. The DPU's built-in network processing engine, encryption engine, and storage controller can efficiently handle these tasks. Flow table management is central to these network functions; the DPU needs to efficiently maintain and query flow tables on hardware or dedicated cores.

[0003] In existing technologies, traditional network devices query flow tables, and each DPU device typically provides command-line tools or proprietary interfaces to obtain flow table information. This approach relies on the syntax and field structure provided by specific device vendors, lacking uniformity. Network controllers or software-defined network controllers (SDN controllers) issue flow table operation commands through their query mechanisms to collect flow table information from each switch (or DPU). While these controllers provide centralized management, their semantic expression capabilities are limited, fields are inconsistent, and extensions are complex.

[0004] Alternatively, some network analytics platforms can collect flow table data, store it in a database, and query specific subsets. These solutions typically rely on post-processing and do not directly interact with the DPU's raw interface, resulting in latency and field discrepancies. Some vendors also provide unified traffic or policy visualization platforms that allow viewing flow table data through a graphical user interface (GUI). However, these platforms are closed and difficult to integrate with standard database semantics (SQL semantics), resulting in poor flexibility and weak query capabilities.

[0005] Therefore, a technical solution is needed to address the issues of diverse query methods, complex management, and lack of unified standard interfaces in heterogeneous DPU flow tables, thereby improving operational efficiency, lowering the barrier to entry, and enhancing the consistency and intelligence of flow table data management across vendor devices. Summary of the Invention

[0006] This invention aims to provide a method, system, DPU cluster, and computing device for querying multi-source DPU flow tables. It can solve problems such as diverse query methods, complex management, and lack of unified standard interfaces for heterogeneous DPU flow tables, improve operation and maintenance efficiency, lower the threshold for use, and enhance the consistency and intelligence of flow table data management across vendor devices.

[0007] According to one aspect of the present invention, a method for querying a multi-source DPU flow table is provided, the method comprising: Receive and parse flow table operation statements, which include the target field for querying and the filtering conditions; The flow table operation statement is converted into a structured semantic tree, and the query target field and the filtering conditions are extracted. Based on the target query field, the filtering conditions, and the DPU information obtained from the DPU information database, generate the corresponding DPU flow table operation command; The flow table operation commands of the corresponding DPUs are sent to the corresponding DPUs to perform the corresponding operations and obtain the return values; The different return values ​​are unified into the final operation result of the logical flow table model field.

[0008] According to some embodiments, all DPU devices within the cluster are scanned to obtain DPU information; The DPU information is registered to the DPU information database.

[0009] According to some embodiments, receiving and parsing the flow table operation statement includes: Receive the flow table operation statement used for querying the task; The flow table operation statements are subjected to syntax analysis, key field extraction, and logical judgment parsing to obtain a parsed structured semantic tree.

[0010] According to some embodiments, based on the query target field, the filtering conditions, and the DPU information obtained from the DPU information database, a flow table operation command for the corresponding DPU is generated, including: Based on the parsed structured semantic tree and the DPU information in the DPU information database, private command templates corresponding to different DPU information are extracted to generate the final flow table operation commands. The types of flow table operation commands include flow table query commands, flow table delete commands, flow table update commands, and flow table modification commands.

[0011] According to some embodiments, the different return values ​​are unified into the final query result of the logical flow table model fields, including: The return value is then standardized. The resulting structured data rows are then uniformly mapped to a virtual flow table data model.

[0012] According to some embodiments, adapter plugins are provided for different types of DPU devices, wherein the adapter plugins are used to encapsulate the differences in command execution between the different types of DPU devices; The adapter plugin sends the flow table operation commands of the corresponding DPU to the corresponding DPU to perform the corresponding operation and obtain the return value.

[0013] According to another aspect of the present invention, a system for querying multi-source DPU flow tables is provided, the system comprising: The operation statement parsing module is used to receive and parse flow table operation statements, which include query target fields and filtering conditions; convert the flow table operation statements into a structured semantic tree and extract the query target fields and the filtering conditions; The command conversion module is used to generate the corresponding DPU flow table operation command based on the query target field, the filtering conditions, and the DPU information obtained from the DPU information database. The DPU adapter module is used to send the flow table operation commands of the corresponding DPU to the corresponding DPU to perform the corresponding operation and obtain the return value. The data integration module is used to unify the different return values ​​into the final operation result of the logical flow table model fields.

[0014] According to some embodiments, the system further includes a user access interface module for submitting the query task and obtaining the final query result.

[0015] According to some embodiments, the user access interface module is configured to: after obtaining the final query result, display it in table, CSV or JSON format and provide an export archive function.

[0016] According to another aspect of the present invention, a computing device is provided, comprising: Processor; and A memory storing a computer program that, when executed by the processor, causes the processor to perform the method described in any of the preceding methods.

[0017] According to another aspect of the present invention, a DPU cluster is provided, comprising: Multiple DPU smart network interface cards, each DPU smart network interface card includes a DPU chip and multiple interfaces, the DPU chip communicates with the outside world through the interfaces; According to the computing device described above, the computing device manages the flow tables of the plurality of DPU smart network interface cards by performing the method described in any of the preceding methods.

[0018] According to embodiments of the present invention, a method for querying multi-source DPU flow tables is provided. The method receives and parses flow table operation statements from query tasks, converts the flow table query statements into a structured semantic tree, extracts the query target fields and filtering conditions, and generates response DPU flow table operation commands based on the query target fields, filtering conditions, and information stored in the DPU information database. This dynamically parses and translates user-inputted standard SQL statements (Structured Query Language) into flow table operation commands supported by various types of DPUs. The flow table operation commands are then sent to the corresponding DPUs to execute the query operations and obtain the return values. The different return values ​​are unified into the final query result of the logical flow table model fields. This achieves unified structured processing and table lookup of the raw data returned by each DPU device, allowing users to view and analyze it in relational data format. By converting general SQL query statements into query instructions adapted to different devices, this invention solves the problems of diverse query methods, complex management, and lack of a unified standard interface for heterogeneous DPU flow tables. It improves operational efficiency, lowers the barrier to entry, and enhances the consistency and intelligence of flow table data management across vendor devices.

[0019] According to some embodiments, the system of the present invention uses SQL semantics as a unified abstraction layer to solve the problem of inconsistent syntax and field structure among multiple DPU devices; it provides a field mapping and command generation mechanism to realize the automatic conversion of logical fields to private commands.

[0020] According to some embodiments, the present invention constructs an extensible multi-DPU adaptation mechanism, supports device plug-in registration and field template management; outputs standard structured query results, adapts to various upper-layer application systems, and facilitates data analysis and integration; and implements a "SQL query framework for DPU flow tables", which greatly improves maintainability and user-friendliness.

[0021] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit the invention. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0023] Figure 1 This diagram illustrates flow table operations in a prior art multi-DPU cluster environment.

[0024] Figure 2 A schematic diagram of a system for querying multi-source DPU flow tables is shown according to an example embodiment.

[0025] Figure 3 A schematic diagram of module relationships according to an example embodiment is shown.

[0026] Figure 4 A flowchart illustrating a method for querying a multi-source DPU flow table according to an example embodiment is shown.

[0027] Figure 5 A block diagram of a computing device according to an exemplary embodiment is shown. Detailed Implementation

[0028] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that the invention will be thorough and complete, and the concept of the exemplary embodiments will be fully conveyed to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0029] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a full understanding of embodiments of the invention. However, those skilled in the art will recognize that the technical solutions of the invention can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of the invention.

[0030] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0031] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0032] It should be understood that, as used herein, the term “and / or” includes all combinations of any one and more of the listed items in relation to each other.

[0033] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of exemplary embodiments, and the modules or processes in the drawings are not necessarily essential for implementing the present invention, and therefore cannot be used to limit the scope of protection of the present invention.

[0034] Currently, see Figure 1In multi-DPU cluster environments, the methods for manipulating flow table information vary due to differences in interfaces, inconsistent field naming, and inconsistent query syntax among DPU vendors. This results in diverse query methods for heterogeneous DPU flow tables, complex management, and a lack of a unified standard interface.

[0035] Traditional network devices use CLI (Command Line Interface) or API (Application Programming Interface) methods to query flow tables: Each DPU (Data Processing Unit) device typically provides command line tools or proprietary API interfaces to obtain flow table information. This method relies on the syntax and field structure provided by specific device manufacturers and lacks uniformity.

[0036] Network controller or SDN controller query mechanism: OpenFlow controllers, such as the Open Network Operating System (ONOS) and the Open Daylight platform, issue flow table operation commands through application programming interfaces (REST APIs) or the OpenFlow protocol to collect flow table information from each switch (or DPU). Although such controllers provide centralized management, they do not have a standard SQL interface, have limited semantic expression capabilities, inconsistent fields, and complex extensions.

[0037] Data acquisition schemes for network observability platforms: Some network analytics platforms can collect flow table data and store it in a database, then query it using a domain-specific language (DSL) or a subset of SQL. These schemes typically rely on post-processing and do not directly interact with the raw interface of the DPU, resulting in latency and field discrepancies.

[0038] Visualized operation and maintenance platform: Some vendors provide unified traffic / policy visualization platforms that allow users to view flow table data through a GUI. However, these platforms are closed and difficult to integrate with standard SQL semantics, resulting in poor flexibility and weak query capabilities.

[0039] Existing technologies do not support standardized SQL queries. Current query methods largely rely on text-based command-line interfaces (CLI), REST APIs, or DSL languages, lacking general SQL syntax and hindering automated integration or interfacing with traditional database systems. Existing technologies are difficult to adapt and extend; when a new DPU device or its version is added, adaptation logic must be redeveloped. Incompatible field semantics severely impede collaborative queries across multiple DPUs. Existing technologies also lack semantic abstraction capabilities, failing to map logical field names to actual fields in the underlying DPU, leading to reliance on human experience for maintenance and low automation levels. Furthermore, the query result structure of existing technologies is inconsistent; the result formats (e.g., tables, byte streams) returned by different DPUs vary significantly, lacking a unified structured encapsulation, making them unsuitable for analysis and interfacing with upper-layer systems.

[0040] To address these issues, this invention proposes a method for querying multi-source DPU flow tables, which can solve problems such as diverse query methods, complex management, and lack of a unified standard interface for heterogeneous DPU flow tables. This improves operational efficiency, lowers the barrier to entry, and enhances the consistency and intelligence of flow table data management across vendor devices.

[0041] Before describing the embodiments of the present invention, some terms or concepts involved in the embodiments of the present invention will be explained.

[0042] DPU: Data Processing Unit, is a programmable processor specifically designed to accelerate data processing tasks. It aims to reduce the burden on the CPU when handling infrastructure tasks such as networking, storage, and security, thereby improving the overall performance and efficiency of the system.

[0043] SQL stands for Structured Query Language. It is a programming language specifically designed for managing and manipulating relational databases. Through SQL, users can easily perform various operations on the database.

[0044] GUI: Graphical User Interface, is a user interface that allows interaction with a computer system through graphical elements (such as windows, icons, menus, buttons, scroll bars, etc.). Users can intuitively use software or operating systems by clicking, dragging, and performing other operations using devices such as a mouse or touchscreen.

[0045] REST API: Application Programming Interface, is an interface design style widely used in web and mobile application backends.

[0046] SDN: Software-Defined Network Controller. The SDN controller is responsible for the centralized management of data forwarding devices such as switches and routers in the network. It communicates with these devices through the southbound interface to achieve centralized control and flexible scheduling of network traffic. At the same time, it provides a northbound interface to upper-layer applications, supporting network programmability.

[0047] OpenFlow: OpenFlow is one of the earliest and most important SDN southbound protocols. It defines the communication method between SDN controllers and network forwarding devices (such as switches and routers), and realizes the separation of the control plane and the data forwarding plane.

[0048] ONOS: Open Network Operating System, is an open-source, high-performance, highly available, distributed SDN controller platform designed specifically for software-defined networking.

[0049] OpenDaylight is an open-source SDN controller platform.

[0050] DSL stands for Domain-Specific Language, a programming language designed for a specific problem domain, as opposed to general-purpose languages ​​(such as Python and Java). Its syntax closely resembles domain terminology, making it easy for domain experts to use and highly expressive, but its applicability is narrower.

[0051] CLI (Common User Interface) is a user interface that allows users to interact with computer systems (such as operating systems, network devices, and applications) through text commands. Users input commands via the keyboard, and the system executes them and returns the results in text format.

[0052] CSV: A simple text file format used to store tabular data (such as spreadsheets or databases). Each row represents a record, and fields are separated by commas. It is commonly used for data import / export.

[0053] JSON: JavaScript Object Notation, a lightweight data-interchange format that is easy for humans to read and write, and also easy for machines to parse and generate. Based on a key-value pair structure, it is widely used for configuration files and front-end and back-end data transfer.

[0054] JDBC is the standard application programming interface in the Java language for executing SQL statements. It provides a unified interface that allows Java programs to connect to and manipulate various relational databases.

[0055] ODBC: Open Database Connectivity, a universal database access standard that supports multiple programming languages ​​to access various databases, has good cross-platform support, and is often used for data reporting.

[0056] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention.

[0057] Figure 2 A schematic diagram of a system for querying multi-source DPU flow tables is shown according to an example embodiment.

[0058] See Figure 2 The multi-source DPU flow table query system includes: a query statement parsing module, used to receive and parse the flow table operation statements of query tasks, wherein the flow table operation statements include query target fields and filtering conditions; converting the flow table operation statements into a structured semantic tree, and extracting the query target fields and the filtering conditions; a command conversion module, used to generate flow table operation commands based on information stored in the DPU information database; a DPU adapter module, used to send the flow table operation commands to at least one corresponding DPU to execute the query operation and obtain the return value; and a data integration module, used to unify the different return values ​​into the final query result of the logical flow table model fields.

[0059] According to some embodiments, the system further includes a user access interface module for submitting the query task and obtaining the final query result. The user access interface module can display the obtained final query result in table, CSV, or JSON format and provide an export / archive function. The user access interface module provides multiple access methods such as CLI, Web, and REST API, allowing operations and maintenance personnel to submit query tasks and obtain results using standard SQL, supporting JDBC / ODBC compatibility and multi-user authentication and access control.

[0060] According to some embodiments, during system initialization, the system loads a system configuration file to obtain configuration information, which provides data for generating the private flow table command. All DPU devices within the cluster are scanned to obtain DPU information, and the configuration information and the DPU information are registered in the DPU information repository for reference in subsequent command conversion logic. The DPU information repository includes: rules supported by each DPU vendor / model / firmware version in the cluster, flow table structure and query interface capabilities, private command mapping rule base path, data standardization and virtual flow table model definition, system operating parameters, security and access control, and cluster and device discovery configuration.

[0061] According to some implementations, vendor / model / firmware version support rules are used to define the types of hardware devices supported by the system and their software version compatibility, for automatically identifying device capabilities and selecting drivers or command sets. Private command mapping rule base paths translate standard SQL statements into device-specific CLI or private API commands in database middleware or southbound protocol gateways. Data standardization and virtual flow table model definitions are used to unify data formats from different sources, defining virtual "streaming data tables" for upper-layer applications to consume (e.g., monitoring, analysis). System operating parameters are used to control the behavior of background services, such as thread count, cache size, and log levels. Security and access control are used to define user permissions, authentication methods, IP whitelists, encryption policies, etc. Cluster and device discovery configurations configure how the system discovers new devices and how it forms a cluster with other nodes.

[0062] According to some embodiments, the operation statement parsing module receives the flow table operation statement of the query task submitted by the user access interface module, performs syntax analysis, key field extraction and logical judgment parsing on the flow table operation statement, obtains the parsed structured semantic tree, and inputs the parsed structured semantic tree into the command conversion module.

[0063] According to some embodiments, the operation statement parsing module receives standard SQL statements submitted by users, performs operations such as syntax analysis, key field extraction, and logical judgment parsing, and passes the parsed structured semantic tree as input to the command conversion module. The operation statement parsing module supports common SQL clauses such as SELECT, WHERE, ORDER BY, and GROUP BY, and supports basic data type and field mapping, such as IP address, port number, and protocol.

[0064] According to some embodiments, the process by which the operation statement parsing module parses the received SQL statement is as follows: First, lexical analysis is performed to segment the input SQL text into tokens (keywords, identifiers, operators, constants, etc.). For example, when the SQL statement "SELECT ... After `FROM flows WHERE src_ip='192.168.0.1' AND dst_port=80;`, it is split into `[SELECT] [` [FROM] [flows] [WHERE] [src_ip] [=] ['192.168.0.1'] [AND][dst_port] [=]

[80] [;]”. After segmentation, syntax analysis is performed. According to SQL syntax rules, the token installation syntax is constructed into an AST (Abstract Syntax Tree), for example: SELECT ├── Columns:

[0065] ├── FROM: flows

[0066] └── WHERE

[0067] ├── Condition 1: src_ip = '192.168.0.1'

[0068] └── Condition 2: dst_port = 80

[0069] After syntactic analysis, semantic extraction is performed to extract key fields or operational logic from the AST and combine them with predefined field mappings (such as IP, port, protocol, MAC, etc.) to form an intermediate structured semantic tree that can be used for subsequent translation.

[0070] According to some embodiments, the command conversion module extracts private command templates corresponding to different DPU information from the conversion rule base based on the parsed structured semantic tree and the DPU information in the DPU information base, and generates the final flow table operation commands. The types of flow table operation commands include flow table query commands, flow table delete commands, flow table update commands, and flow table modification commands.

[0071] According to some embodiments, the transformation rule base is used to perform functional abstraction, 5-tuple matching, querying, counting, projection, and aggregation on flow table operation statements. Functional abstraction involves transforming the flow table operation statements into private command templates. The transformation rule base does not support marking missing functionalities.

[0072] According to some embodiments, the command conversion module extracts the corresponding private command template from the conversion rule base based on the SQL parsing results and the DPU type, version, and manufacturer information registered in the current cluster, and generates the final device query instruction.

[0073] According to some embodiments, the input information of the command conversion module is the parsing result of the operation statement parsing module, i.e., the AST / semantic tree. The DPU metadata in the AST includes type (such as network DPU, storage DPU, security DPU), vendor, hardware version, or feature (e.g., whether it supports 5-tuple matching, whether it supports regular expressions, whether it supports hardware aggregation).

[0074] According to some implementations, the matching process in the conversion rule base is as follows: Feature mapping: For example, WHERE ip = 10.0.0.1 can be mapped to a five-tuple matching condition; GROUP BY src_ip is mapped to aggregation statistics capability. Capability matching: The DPU capability description table is queried to see if the current model supports five-tuple matching, aggregation, etc., to achieve capability matching. Template selection: In the conversion rule base, a set of private command templates is maintained for each DPU and its corresponding function. Based on the private command templates, according to the results parsed by the operation statement parsing module, i.e., the set of functional requirements, a template that can be satisfied is searched in the rule base. If there is a complete match, the flow table operation command is directly generated; if there is a partial match, the degradation logic is followed, such as sinking the aggregation to the software layer.

[0075] According to some embodiments, the transformation rule base includes private command templates. SQL semantics are functionally abstracted; for example, SELECT performs querying, counting, and projection; WHERE ip=X performs 5-tuple matching; and GROUP BY performs aggregation. Corresponding private command templates are then created after functional abstraction. For example, DPU_A_v1: filter ip=xx and DP_B_v2: match --src-ip=xx. Initially, the transformation rule base is created manually, with engineers writing the corresponding SQL functions and DP commands into JSON / YAML / database tables based on the manufacturer's command manual. Later, an automated driver registration mechanism is implemented; each DPU driver registers its capabilities and command templates with the rule base during initialization. Rules can be formalized using JSON / YAML, for example: - dpu: "Pensando_v1" sql_feature: "WHERE ip=X" command: "match src_ip={X}" or, - dpu: "Pensando_v1" sql_feature: "COUNT" command: "counter enable" According to some embodiments, the command conversion module supports cross-vendor flow table operation command semantic mapping, and the conversion rule base is extensible, supporting hot updates and vendor-specific customization. The implementation of cross-vendor flow table queries first establishes a unified abstract model, defining standardized flow table operation semantics (e.g., matching conditions, actions, statistical fields). Similar to the OpenFlow / P4 Runtime approach, DPU commands are abstracted into MATCH {fields}, ACTION {actions}, and STAT {counters}, and user SQL is converted into UAM expressions. Based on the rule mapper, different vendor driver modules are responsible for mapping UAM (Unified Account and Authentication Management) to vendor-specific commands.

[0076] The expansion of the transformation rule base includes: interface expansion, allowing a single SQL query to be executed through different interfaces. For example, a user can log in to a network device via a terminal and manually enter the `show flows` command, and the system will return the current flow table information (CLI → showflows); or retrieve flow data by sending an HTTP GET request to a service's interface (API → GET / flow). Optimization / strategy expansion supports SQL query optimization, such as... The "FROM flows ORDER BY packets DESCLIMIT 10" function is broken down into "DPU-side Top-N queries" + "control plane aggregation" to reduce data volume. Operations are expanded to include SELECT, DELETE, UPDATE, and INSERT. Statistics / monitoring are extended to support higher-level SQL aggregations.

[0077] According to some embodiments, the DPU adapter module provides adapter plugins for different types of DPU devices. These plugins distribute flow table operation commands for the corresponding DPUs to the respective DPUs for execution and return values. The adapter plugins encapsulate the differences in command execution between the DPU devices, including command distribution, authentication, and result parsing. The DPU adapter module provides a unified interface encapsulation (such as `execute_query(dpu_id, command)`), supporting synchronous / asynchronous and push-pull query methods.

[0078] According to some embodiments, the data integration module standardizes the return values ​​returned by the DPU adapter module to obtain structured data rows, and then maps these structured data rows uniformly to a virtual flow table data model. The data integration module also standardizes the raw query results (JSON, tables, key-value pairs, etc.) returned by each DPU to convert them into structured data rows, and then maps them uniformly to a virtual flow table data model. The data integration module supports operations such as field alignment, unit unification, data formatting, pagination, deduplication, error retries, and aggregation.

[0079] According to some implementations, standardization unifies the names, units, values, and formats of fields with the same semantic meaning, resulting in standardized, consistent, and comparable values. Structured data rows, on the other hand, organize an observation / stream record into a row by columns under a fixed schema (column definitions, data types, units). These rows have clearly defined column names, types, and units, and can be directly stored in a table (DB / data lake / column storage / time series database) or queried as a virtual stream table. The difference between standardization and structured data lies in how they address the issue of "value consistency," i.e., unifying the same semantic meaning, while structured data addresses the issue of "how to store / query" the data.

[0080] According to some embodiments, the steps for standardizing and converting data into structured rows include: data acquisition, obtaining the raw query results from the DPU, which may be JSON / table / key-value pairs; parsing different formats to obtain intermediate key-value pairs through a JSON parser, table splitter, or KV splitter; field mapping, unifying different units into a standard; and filling the unified fields into the system-defined virtual flow table schema to achieve structured alignment.

[0081] According to some implementations, data acquisition involves obtaining the raw query results from the DPU, which may be JSON / table / key-value pairs. For example, the differences in data returned by different vendors: Vendor A (JSON): {"sip":"1.1.1.1","dip":"2.2.2.2","proto":6,"len":1000}; Vendor B (table): SIP=1.1.1.1, DIP=2.2.2.2, PROTO=TCP, BYTES=1KB.

[0082] According to some embodiments, parsing key-value pairs includes parsing different formats, which can be done using a JSON parser, table splitter, and KV splitter to obtain intermediate key-value pairs. For example, A → {sip: "1.1.1.1", dip: "2.2.2.2", proto: 6, len: 1000}; B → {SIP: "1.1.1.1", DIP: "2.2.2.2", PROTO: "TCP", BYTES: "1KB"}.

[0083] According to some embodiments, field mapping is performed based on a field mapping table, mapping vendor-specific fields to system standard fields. For example, sip / SIP → src_ip, dip / DIP → dst_ip, proto / PROTO → protocol, len / BYTES → bytes. Different units and types are standardized to ensure that the data type of each field conforms to the model requirements; for example, "1KB" → 1024, "TCP" → 6 (protocol number), "1000" → 1000 (bytes).

[0084] According to some implementations, structured alignment involves filling the unified fields into a system-defined virtual flow table, for example: { "src_ip": "1.1.1.1", "dst_ip": "2.2.2.2", "src_port": 12345, "dst_port": 80, "protocol": "TCP", "bytes": 1000, "packets": null } Fields that do not exist here (such as packets) can be filled with null or 0.

[0085] According to some embodiments, the system of the present invention supports result caching to reduce duplicate queries. Results can be cached in the controller's local cache, distributed cache, or DPU device's local cache, reducing repeated access to the DPU, improving query speed, reducing hardware pressure, and simultaneously, with audit logs, it is possible to track whether the cache has been hit.

[0086] According to some embodiments, the system of the present invention further includes a timed scheduling module. The timed scheduling module is used to automatically execute tasks for the system according to a pre-set time or period, without relying on manual triggering. Timed scheduling can achieve automated data collection, avoid manual querying, and ensure continuous data updates.

[0087] According to some embodiments, the implementation of scheduled tasks includes: Task registration: During system initialization, tasks that need to be executed on a schedule are registered with the scheduler. Each task includes an execution action (function / script), execution period (e.g., every 5 seconds, every 4 minutes, or every morning), priority, or dependencies; Scheduler core: The system can use its built-in traditional cron / timer or a built-in scheduling module. The core functions of the scheduler include calculating the next execution time, triggering the corresponding task, and supporting concurrent or sequential execution. The technical implementation of the core scheduler is based on memory queues and timers, or threads or coroutine pools to execute tasks; Task execution and management: Execute task functions, such as query_flow_table(), supporting exception handling (to prevent the scheduler from crashing), logging, and caching or snapshot saving of execution results. Scheduled tasks can be extended and controlled, supporting adding, deleting, modifying, and querying tasks (i.e., hot updating the scheduling table), and supporting user permissions to restrict which users can create or modify tasks.

[0088] According to some implementations, the timed scheduling module automates data collection, flow table snapshot recording, cache refresh and cleanup, ensures security and auditing, and reduces operational burden. Automated data collection avoids manual querying and ensures continuous data updates; for example, it collects flow table snapshots every minute. Flow table snapshot recording generates historical traffic data snapshots through timed capture, facilitating trend analysis and anomaly detection. Cache refresh and cleanup triggers cache invalidation or updates at regular intervals, ensuring the freshness of queried data. Regularly executed tasks can record logs and user information, facilitating security compliance, ensuring security and auditing, avoiding omissions from manual operations, and forming an automated audit trail. The system automatically completes repetitive tasks, improving efficiency, supporting large-scale cluster management, and effectively reducing operational burden.

[0089] According to some embodiments, the various modules of this invention work collaboratively; the module relationships are described in [reference needed]. Figure 3This invention utilizes an intermediate interpretation, analysis, and transformation layer designed between SQL statements and various DPU flow table commands to achieve unified querying of flow table data using standard SQL across heterogeneous device clusters. The standardized query method eliminates the need for users to learn the dedicated command interfaces for each DPU; they can perform operations such as conditional filtering, field selection, sorting, and aggregation of flow tables directly through SQL. This invention effectively masks inter-device differences, automatically recognizing the command formats and semantic differences of various DPUs. Users do not need to understand the underlying structure and protocols, significantly improving operational efficiency.

[0090] According to some embodiments, this invention supports cross-version and cross-vendor queries, connecting to DPUs from various manufacturers and versions, thus solving the problem of version fragmentation. The system of this invention supports flexible expansion; the command translation module and device adapter are hot-swappable, supporting rapid adaptation to future new DPU models, and possesses good versatility and maintainability.

[0091] According to some embodiments, the system of the present invention effectively improves the efficiency of fault diagnosis. Combining the rapid filtering capabilities of SQL, the system can quickly locate problematic rules or abnormal flows in large-scale flow table data, improving both accuracy and speed. This invention reduces labor and training costs, eliminates the need to master the underlying device command system, and is easier to learn and integrate using SQL.

[0092] Figure 4 A flowchart illustrating a method for querying a multi-source DPU flow table according to an example embodiment is shown.

[0093] See Figure 4 In S301, the flow table operation statement is received and parsed, which includes the query target field and the filtering conditions.

[0094] According to some embodiments, after the system starts up, it first performs initialization, loads the configuration file and scans all DPU devices in the cluster. Each DPU reports its manufacturer, model, firmware version, flow table structure and query interface capabilities. The system registers this information in the DPU information database for reference in subsequent command conversion logic.

[0095] According to some embodiments, the contents of the configuration file include: vendor / model / version support rules; SQL → private command mapping rule base path; data standardization and virtual flow table model definition; system operating parameters; security and access control; cluster and device discovery configuration.

[0096] In S303, the flow table operation statement is converted into a structured semantic tree, and the query target field and the filtering conditions are extracted.

[0097] According to some implementations, after receiving a flow table operation statement, the target field and filtering conditions in the flow table operation statement are parsed. For example, an operations and maintenance personnel enter the following SQL statement in the console: SELECT src_ip, dst_ip, packet_count FROM flow_table WHERE dst_port = 443 AND protocol = 'TCP'; Parsing the SQL statement, "From the flow_table table (FROM flow_table), find and return all network connection records with a destination port of 443 (dst_port = 443) and using the TCP protocol (protocol = 'TCP'), and display the source IP address (src_ip), destination IP address (dst_ip), and number of packets transmitted (packet_count) for these connections," we find that the target fields are "src_ip, dst_ip, packet_count," and the filter conditions are "FROM flow_table, dst_port = 443, protocol = 'TCP'."

[0098] In S305, based on the query target field, the filtering conditions, and the DPU information obtained from the DPU information database, a flow table operation command for the corresponding DPU is generated.

[0099] According to some embodiments, the command conversion module receives the parsed structured semantic tree and generates corresponding flow table operation commands based on the capabilities of each DPU.

[0100] According to some implementations, based on AST and DPU metadata, such as type (e.g., network DPU, storage DPU, security DPU), vendor (e.g., Marvell, Pensando, Nvidia, etc.), hardware version / features (e.g., whether it supports 5-tuple matching, whether it supports regular expressions, whether it supports hardware aggregation, etc.), feature mapping and capability matching are performed to obtain a set of functional requirements. Then, based on the set of functional requirements, a template that can be satisfied is searched in the transformation rule base.

[0101] For example, for a DPU of model A, the conversion is: show flows --filter "dst_port=443,protocol=6" For DPU model B, convert to JSON-RPC calls: { "method": "query_flows", "params": {"dst_port": 443, "proto": "tcp"}, "id": 1 } In S307, the flow table operation commands of the corresponding DPUs are sent to the corresponding DPUs to perform the corresponding operations and obtain the return values.

[0102] According to some embodiments, the DPU adapter module sends the commands in S305 to the corresponding DPUs, executes them, and retrieves the return values.

[0103] In S309, the different return values ​​are unified into the final operation result of the logical flow table model field.

[0104] According to some implementations, the data integration module unifies the return results in different formats into logical flow table model fields, as shown in Table 1: Table 1

[0105] According to some implementations, the final results are returned to the user in tabular, CSV, or JSON format and can be exported for archiving.

[0106] According to some embodiments, the system of the present invention uses SQL semantics as a unified abstraction layer to solve the problem of inconsistent syntax and field structure among multiple DPU devices; it provides a field mapping and command generation mechanism to realize the automatic conversion of logical fields to private commands.

[0107] According to some embodiments, the present invention constructs an extensible multi-DPU adaptation mechanism, supports device plug-in registration and field template management; outputs standard structured query results, adapts to various upper-layer application systems, and facilitates data analysis and integration; and implements a "SQL query framework for DPU flow tables", which greatly improves maintainability and user-friendliness.

[0108] According to embodiments of the present invention, the present invention also provides a DPU cluster, including multiple DPU smart network interface cards (NICs), each DPU smart NIC including a DPU chip and multiple interfaces, wherein the DPU chip communicates externally through the interfaces; according to Figure 5 The computing device manages the flow tables of the plurality of DPU smart network interface cards by performing the method described in any of the preceding methods.

[0109] In summary, this invention provides a system and method for unified operation of flow table information in a multi-DPU cluster environment, solving problems such as diverse operation methods, complex management, and lack of a unified standard interface for heterogeneous DPU flow tables. This method uses semantic analysis and command conversion modules as an intermediate interpretation layer to dynamically parse and translate user-input standard SQL statements into private flow table operation commands supported by various DPUs. Finally, it performs unified structured processing and table lookup on the raw data returned by each device, allowing users to view and analyze it in relational data format.

[0110] This invention allows users to use familiar SQL language, such as "SELECT ... The command "FROM flow_table WHERE src_ip='10.0.0.1'" allows direct querying, filtering, aggregation, and analysis of all types of DPU flow table data without needing to concern themselves with the implementation details of the underlying devices. This improves operational efficiency, lowers the barrier to entry, and enhances the consistency and intelligence of flow table data management across vendor devices.

[0111] Figure 5 A block diagram of a computing device according to an exemplary embodiment of the present invention is shown.

[0112] like Figure 5 As shown, the computing device 30 includes a processor 12 and a memory 14. The computing device 30 may also include a bus 22, a network interface card 16, and an I / O interface 18. The processor 12, memory 14, network interface card 16, and I / O interface 18 can communicate with each other via the bus 22.

[0113] Processor 12 may include one or more general-purpose CPUs (Central Processing Units), microprocessors, or application-specific integrated circuits, for executing relevant program instructions. According to some embodiments, computing device 30 may also include a high-performance display adapter (GPU) 20 for accelerating processor 12.

[0114] Memory 14 may include a machine system readable medium in the form of volatile memory, such as random access memory (RAM), read-only memory (ROM), and / or cache memory. Memory 14 is used to store one or more programs containing instructions, as well as data. Processor 12 may read the instructions stored in memory 14 to perform the methods described above according to embodiments of the present invention.

[0115] The computing device 30 can also communicate with one or more networks via the network interface card 16. The network interface card 16 can be a DPU smart network card.

[0116] Bus 22 can include address bus, data bus, control bus, etc. Bus 22 provides a path for exchanging information between components.

[0117] It should be noted that, in specific implementations, the computing device 30 may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the device described above may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0118] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), network storage devices, cloud storage devices, or any type of medium or device suitable for storing instructions and / or data.

[0119] This invention also provides a computer program product comprising a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments.

[0120] Those skilled in the art will clearly understand that the technical solutions of the present invention can be implemented by means of software and / or hardware. In this specification, "unit" and "module" refer to software and / or hardware capable of independently performing or cooperating with other components to perform a specific function, wherein the hardware may be, for example, a field-programmable gate array (FPGA), an integrated circuit, etc.

[0121] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0122] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0123] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus 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 service interface; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0124] 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.

[0125] Furthermore, the functional units in the various embodiments of the present invention 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0126] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 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 of the various embodiments of the present invention.

[0127] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0128] Exemplary embodiments of the present invention have been specifically shown and described above. It should be understood that the present invention is not limited to the detailed structures, arrangements, or implementations described herein; rather, the present invention is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended provisions.

Claims

1. A method for querying a multi-source DPU flow table, characterized in that, The method includes: Receive and parse flow table operation statements, which include the target field for querying and the filtering conditions; The flow table operation statement is converted into a structured semantic tree, and the query target field and the filtering conditions are extracted. Based on the target query field, the filtering conditions, and the DPU information obtained from the DPU information database, generate the corresponding DPU flow table operation command; The flow table operation commands of the corresponding DPUs are sent to the corresponding DPUs to perform the corresponding operations and obtain the return values; The different return values ​​are unified into the final operation result of the logical flow table model field.

2. The method according to claim 1, characterized in that, The method further includes: Scan all DPU devices within the cluster to obtain DPU information; The DPU information is registered to the DPU information database.

3. The method according to claim 1, characterized in that, The receiving and parsing of flow table operation statements includes: Receive the flow table operation statement used for querying the task; The flow table operation statements are subjected to syntax analysis, key field extraction, and logical judgment parsing to obtain a parsed structured semantic tree.

4. The method according to claim 3, characterized in that, Based on the target query field, the filtering conditions, and the DPU information obtained from the DPU information database, generate the corresponding DPU flow table operation commands, including: Based on the parsed structured semantic tree and the DPU information in the DPU information database, private command templates corresponding to different DPU information are extracted to generate the final flow table operation commands. The types of flow table operation commands include flow table query commands, flow table delete commands, flow table update commands, and flow table modification commands.

5. The method according to claim 1, characterized in that, The different return values ​​are unified into the final query result of the logical flow table model fields, including: The return value is then standardized. The resulting structured data rows are then uniformly mapped to a virtual flow table data model.

6. The method according to claim 1, characterized in that, The method further includes: Adapter plugins are provided for different types of DPU devices, wherein the adapter plugins are used to encapsulate the differences in command execution between the different types of DPU devices; The adapter plugin sends the flow table operation commands of the corresponding DPU to the corresponding DPU to perform the corresponding operation and obtain the return value.

7. A system for querying multi-source DPU flow tables, characterized in that, The system includes: The operation statement parsing module is used to receive and parse flow table operation statements, which include query target fields and filtering conditions; convert the flow table operation statements into a structured semantic tree and extract the query target fields and the filtering conditions; The command conversion module is used to generate the corresponding DPU flow table operation command based on the query target field, the filtering conditions, and the DPU information obtained from the DPU information database. The DPU adapter module is used to send the flow table operation commands of the corresponding DPU to the corresponding DPU to perform the corresponding operation and obtain the return value. The data integration module is used to unify the different return values ​​into the final operation result of the logical flow table model fields.

8. The system according to claim 7, characterized in that, The system also includes a user access interface module, used to submit the query task and obtain the final query result.

9. The system according to claim 8, characterized in that, The user access interface module is configured to: after obtaining the final query results, display them in table, CSV, or JSON format and provide an export archive function.

10. A computing device, characterized in that, include: processor; as well as A memory storing a computer program that, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-6.

11. A DPU cluster, characterized in that, include: Multiple DPU smart network interface cards, each DPU smart network interface card includes a DPU chip and multiple interfaces, the DPU chip communicates with the outside world through the interfaces; The computing device according to claim 10, wherein the computing device manages the flow tables of the plurality of DPU smart network interface cards by performing the method according to any one of claims 1-6.

Images