Compiling method and system based on p4c compiler backend and electronic equipment

Abstract

The application provides a compiling method and system based on a P4C compiler backend and electronic equipment, and relates to the field of compilers, and solves the technical problem of low performance efficiency of a P4 processor for hardware resources. The method comprises the following steps: obtaining an IR node processed by a P4C backend through an API library; converting semantic description data of the IR node into JSON format data based on the IR node processed by the P4C backend, and taking the JSON format data as input of a P4 runtime; traversing the JSON format data and respectively parsing P4 program semantics described in the JSON format data; respectively generating special machine code firmware files of a network card hardware unit based on the P4 program semantics, the special machine code firmware files including a parser, a matching execution unit and a deparser, and obtaining an IR descending compilation result from a P4 program IR to hardware machine code.

Description

Technical Field

[0001] This application relates to the field of compiler technology, and in particular to a compilation method, system and electronic device based on the P4C compiler backend. Background Technology

[0002] Currently, P4 (Programming Protocol-Independent Packet Processors) is a programmable protocol-independent packet processor. In hardware, it refers to a dedicated network packet processor. Accompanying it at the software level is a high-level programming language specifically designed to describe the logic of network packet processing. Generally, the program consists of three core components: a parser, a control block, and a deparser. Network protocols or network applications written in this language can be compiled and run on hardware processors that support P4, realizing the programming of network packet editing logic.

[0003] Each hardware manufacturer's P4 processor is generally designed with proprietary machine instructions and dedicated compilers, but for various reasons, they choose not to disclose the relevant technical information. The P4C compiler that comes with it is also completely closed source. The P4 JSON output by the open source P4C compiler cannot be directly used for a specific P4 processor. It can only be used as a general intermediate representation (IR) generated during the compilation process, and at most it can only be used to drive the BMv2 software simulator. Therefore, smart network cards can only design and implement the P4C compiler backend according to the characteristics of their self-developed P4 processor, resulting in low performance efficiency of the P4 processor for hardware resources. Summary of the Invention

[0004] The purpose of this invention is to provide a compilation method, system, and electronic device based on a P4C compiler backend, in order to solve the technical problem that existing P4 compiler backends cannot efficiently compile general P4 programs into dedicated smart network card machine code firmware, resulting in low performance efficiency of the P4 processor for hardware resources.

[0005] Firstly, this application provides a compilation method based on a P4C compiler backend, the method comprising: Obtain the API (Application Programming Interface) library containing the front-end and middle-end of P4C (Programming Protocol-Independent Packet Processors Compiler, an open-source reference compiler framework maintained by the P4 language community), and obtain the IR (Intermediate Representation, an abstract program representation used by the compiler during the compilation process) node after processing by the middle-end of P4C through the API library; Based on the IR node after processing in the P4C middleware, the semantic description data of the IR node is converted into JSON (JavaScript Object Notation) format data, and the JSON format data is used as the input of P4 (Programming Protocol-Independent Packet Processors) runtime. The JSON format data is traversed and the P4 program semantics described in the JSON format data are parsed respectively; wherein, the P4 program semantics include at least one of the following: Parser (a state machine component in the P4 program that describes message parsing), action (an operation sequence defined in the P4 program), control (a component in the P4 program that describes matching action processing), deparser (a control block in the P4 program that reassembles the processed header fields into the output message), external extension extern object (a functional object provided by the P4 architecture), and checksum csum; Based on the semantics of the P4 program, dedicated machine code firmware files for the network card hardware units corresponding to the Parser, Match-Action Table (MAT), and Deparser are generated respectively, resulting in the IR downcompilation compilation result of the P4 program from IR to hardware machine code.

[0006] In one possible implementation, it also includes: For each ParserState node in the IR node, extract the parser state, parser operator, parser state transition, and parser state key to generate a JSON representation of the state node. Iterate through the JSON representation results of the state nodes to obtain the corresponding hardware machine instructions and generate the parser state machine code. After completing all user program states, a checksum state is dynamically created as the parser's last state based on whether the user has defined a checksum verification process. This state is then used to execute the calculation of the user-specified checksum algorithm and generate Parser Checksum machine code. The checksum algorithm calculation includes at least one of CSUM16, CRC16, and CRC32.

[0007] In one possible implementation, it also includes: Iterate through each P4 Action node in the IR node and generate a JSON representation of the Action node; Based on the JSON representation result of the Action node, the machine instructions of the MAT unit are converted to generate MAT machine code.

[0008] In one possible implementation, it also includes: Iterate through each P4 Control node in the IR nodes, and convert the P4 Control node into a JSON representation of the Control node; the Control type of the Control node is Deparser. The JSON representation of the Control node is converted into machine code to generate Deparser machine code.

[0009] In one possible implementation, it also includes: Both the network interface card's Parser and MAT are matched through table entries. The types and specifications of these table entries include TCAM (Ternary Content Addressable Memory), HASH (a hardware table entry type based on a hash algorithm), and CACHE (a hardware table entry type based on a caching mechanism). The method also includes: The parser state is converted into TCAM entry generation results, and the transition select related data of P4 Parser is converted into Parser TCAM entries; Convert the matching type of the P4 data table (the matching table defined in the P4 program) into a TCAM table entry. The matching type includes at least one of the following: exact match, ternary match, longest prefix match (lpm), and optional match. Convert the exact match of the P4 table into a HASH table entry or a cached hardware table entry. The allocation of resources for the corresponding entries in the TCAM table, the HASH table, and the CACHE hardware table is automatically determined by the compiler based on the resource consumption of the application.

[0010] In one possible implementation, the pipeline of the P4 processor is determined by the TUNA (Native Unified Multimodal Model) architecture model, which is used to abstract the hardware core data of the P4 processor into APIs. The core architecture of the TUNA architecture model includes the IngressPipeline package, the EgressPipeline package, and the top-level architecture definition TUNANIC package. The IngressPipeline package contains programmable blocks for IngressParser, VerifyChecksum, Ingress Control, ComputeChecksum, and IngressDeparser, which are used to support two types of metadata parameterization: RECIRCM (Recycled Metadata) and NM (Number of Metadata Transferred Between Pipelines). The EgressPipeline package contains programmable blocks for EgressParser, VerifyChecksum, Egress Control, Checksum Calculation and ComputeChecksum, and EgressDeparser. The top-level architecture of TUNANIC includes an ingress pipeline component, a packet replication engine component, an egress pipeline component, and a buffering queuing engine component, which are used to form a complete network interface card data plane.

[0011] In one possible implementation, the TUNA architecture model includes a hardware-supported hash algorithm enumeration HashAlgorithm for the P4 processor and multiple externally extended EXTERN functions for calculating the checksum csum. The hash algorithm enumeration HashAlgorithm includes: checksum CSUM, cyclic redundancy check CRC16, CRC32, TUNA custom CRC32, exclusive OR (XOR) 4, XOR 8, XOR 16, XOR 32, and Toeplitz hash; The multiple external extension functions include the verify_checksum function, the update_checksum function, the verify_checksum_with_payload function, and the update_checksum_with_payload function.

[0012] Secondly, this application provides a compilation system based on the P4C compiler backend, including: The acquisition module is used to acquire an API library containing the P4C front-end and mid-end, and to obtain the IR node after P4C mid-end processing through the API library; The conversion module is used to convert the semantic description data of the IR node after processing by the P4C into JSON format data, and use the JSON format data as the input of the P4 runtime. The parsing module is used to traverse the JSON format data and parse the P4 program semantics described in the JSON format data respectively; wherein, the P4 program semantics includes at least one of the following: Parser state machine, action operation, control pipeline, Deparser sending sequence, extern object instance, and checksum; The generation module is used to generate dedicated machine code firmware files for the network card hardware units corresponding to the parser, matching execution unit, and deparser based on the semantics of the P4 program, so as to obtain the IR downcompilation result of the P4 program to the hardware machine code.

[0013] Thirdly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the method described in the first aspect above.

[0014] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method described in the first aspect above.

[0015] This application brings the following beneficial effects: This application provides a compilation method, system, and electronic device based on a P4C compiler backend, which can obtain the P4C mid-processed IR node through the API library; convert the semantic description data of the IR node into JSON format data based on the P4C mid-processed IR node, and use the JSON format data as input to the P4 runtime; traverse the JSON format data and parse the P4 program semantics described in the JSON format data respectively; wherein, the P4 program semantics include at least one of the following: parser state machine, action operation, control pipeline, deparser send sequence, external extension extern object instance, and checksum csum; based on the P4 program semantics, generate dedicated machine code firmware files for the network card hardware units corresponding to the parser, matching execution unit MAT, and deparser, respectively, to obtain the IR downcompilation compilation result from P4 program IR to hardware machine code; in this solution, the P4 JSON of the open-source P4C ecosystem is used. Using IR as input, the lowering compilation method from P4 program IR to hardware machine code supports compiling general-purpose P4 programs into dedicated machine code firmware for smart network cards. It provides a compilation method that lowers the P4 program IR to the machine code of the three hardware units of the smart network card: parser, MAT, and deparser. This completes the compilation of general-purpose P4 language into executable machine code firmware for the smart P4 processor. It implements the P4C compiler backend, enabling the compilation of programs written in P4 language into firmware for smart network cards. This allows for programming smart network cards using P4 language, closely aligning with the P4 processor's hardware resources for deep optimization of network protocols, thereby improving performance and solving the technical problem of low performance effectiveness of the P4 processor in utilizing hardware resources.

[0016] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 A schematic flowchart of the compilation method based on the P4C compiler backend provided in the embodiments of this application; Figure 2 Another flowchart illustrating the compilation method based on the P4C compiler backend provided in this application embodiment; Figure 3 A schematic diagram of the structure of a compilation system based on a P4C compiler backend is provided for embodiments of this application; Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

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

[0020] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this application, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0021] Currently, P4C is an open-source reference compiler maintained by the P4 community. Its framework is divided into a front-end, a middleware, and a back-end. Hardware manufacturers can develop their own compiler back-ends based on the P4C front-end and middleware, converting the IR processed by the P4C middleware into outputs for different targets. The P4 community also provides a general output format, namely P4 JSON (e.g., the BMv2JSON format defined by the p4lang / behavioral-model project). Its top-level fields include parsers, pipelines, deparsers, actions, headers, and extern_instances, which fully describe the parser state machine, matching action pipeline (including the key elements and actions of each table), inverse parser emit sequence, extern object instances, and source code location information of each primitive in the P4 program.

[0022] The general JSON format can typically only be used on simulators implemented in the P4 community reference, i.e.: 1. BMv2 Soft Switch Backend: BMv2 (Behavioral Model v2) is a P4 software simulator developed by the p4lang community. Its P4C backend compiles P4 programs into BMV2 JSON format files. When the BMv2 simulator runs, it directly loads the JSON file and drives the software simulator to execute the semantics of the P4 program. The BMV2 P4C compiler backend does not generate any hardware machine code.

[0023] The aforementioned general output format cannot be directly run on a specific P4 processor. Therefore, P4 processors from different manufacturers typically come with independent compilation backends to further convert the intermediate representation (IR) generated during compilation into a format supported by their respective hardware, such as: 2. Barefoot / Intel Tofino backend: It uses a proprietary closed-source compiler to generate binary files specifically for the Tofino switching chip directly from the intermediate representation (IR) inside the P4C compiler. It does not use JSON as the data plane output format. Its compilation process and machine code generation method are not disclosed.

[0024] 3. Xilinx FPGA P4 backend: Compiles P4 programs into FPGA Hardware Description Language (HDL) to generate synthesizable hardware circuits.

[0025] Each hardware manufacturer's P4 processor is generally designed with proprietary machine instructions and dedicated compilers, but for various reasons, they choose not to disclose the relevant technical information. The P4C compiler that comes with it is also completely closed source. The P4 JSON output by the open source P4C compiler cannot be used directly for a specific P4 processor. It can only be used as a general intermediate representation (IR) generated during the compilation process. At most, it can only be used to drive the BMv2 software simulator. Therefore, smart network cards can only design and implement the P4C compiler backend according to the characteristics of their self-developed P4 processor, resulting in low flexibility of the P4C compiler backend.

[0026] Based on this, embodiments of this application provide a compilation method, system, and electronic device based on a P4C compiler backend, which can solve the technical problem of low performance efficiency of P4 processors in response to hardware resources.

[0027] The embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0028] Figure 1 This is a flowchart illustrating a compilation method based on a P4C compiler backend, provided as an embodiment of this application. Figure 1 As shown, the method includes: Step S110: Obtain the API library containing the P4C front-end and mid-end, and obtain the IR node after P4C mid-end processing through the API library.

[0029] It should be noted that P4 refers to Programming Protocol-Independent Packet Processors, which is also a high-level programming language specifically designed to describe network packet processing logic. P4C refers to P4 Compiler, an open-source reference compiler framework maintained by the P4 language community, providing front-end and mid-end processing capabilities for P4 programs and supporting the extension of compilation back-ends for different targets as standalone executable programs. IR refers to Intermediate Representation, an abstract program representation used by the compiler during the compilation process, situated between the source code and the object code. The smart network interface card (NIC) is equipped with a programmable P4 processor, allowing for flexible editing of network packets and adaptability to various network protocols and application scenarios. The NIC refers to a smart network interface card that supports P4 programming, which is the target hardware platform of this invention.

[0030] In practical applications, the execution of the tunic compiler backend in this solution is divided into two stages: the first stage (JSON generation): by inheriting the open-source library that includes the APIs of the P4C frontend and middleend, the IR processed by the P4C middleend is obtained (this IR will be used as input for the second stage). Step S120: Based on the semantic description data of the IR node after processing by the P4C middleware, convert the semantic description data of the IR node into JSON format data, and use the JSON format data as the input of the P4 runtime.

[0031] In the first stage described above, based on this IR, the relevant semantic description is further converted into JSON format. This JSON format will serve as auxiliary information for the subsequent second stage and will be used as input to the P4 runtime.

[0032] It should be noted that P4 JSON IR refers to the intermediate JSON format representation output by the P4C compiler (BMv2 v2.xx specification), defined by the p4lang community's behavioral-model project, and includes top-level fields such as parsers, pipelines, deparsers, actions, and headers. This invention uses this as input to compile hardware machine code firmware for a dedicated smart network interface card. Here, BMv2 refers to Behavioral Model v2, a P4 software emulator developed by the p4lang community that defines the standard format of P4 JSONIR. Firmware refers to the binary data written to the target network interface card's hardware registers and memory.

[0033] Step S130: Traverse the JSON format data and parse the P4 program semantics described in the JSON format data respectively.

[0034] The P4 program semantics include at least one of the following: the Parser state machine, the action operation, the control pipeline, the Deparser sending sequence, the external extension extern object instance, and the checksum csum.

[0035] In the second stage (machine code firmware generation) following the first stage described above: The core of this invention involves traversing the IR nodes processed by the P4C intermediate layer and directly generating dedicated machine code firmware for the three hardware units (Parser, MAT, and Deparser) of the smart network interface card based on the P4 program semantics described in the IR. The specific execution steps of the second stage include: traversing the JSON output from the first stage and parsing its semantics, such as the parser state machine, action operations, control pipeline, deparser sending sequence, extern object instance, and checksum.

[0036] In this context, MAT refers to the Match-Action Table, a first-level processing unit in the target network interface card's (NIC) match-action pipeline. Parser refers to the state machine component in the P4 program that describes packet parsing, extracting protocol header fields from the packet byte stream. Control refers to the component in the P4 program that describes match-action processing, including table and action declarations and control logic. Action refers to the sequence of operations defined in the P4 program, including basic operations such as field modification, field copying, and arithmetic operations. Extern objects refer to functional objects provided by the P4 architecture, such as hash calculations, counters, and checksums. Deparser refers to the control block in the P4 program that reassembles the processed header fields into the output packet. Table refers to the match table defined in the P4 program, containing match keys, match types, and associated actions.

[0037] As an example, a general compilation rule is that the fields of each operation primitive in JSON (such as op, parameters, value, mask, etc.) are converted into the corresponding fields of the machine instruction (opcode, source / target operand offset, source / target operand length, source / target operand selection, immediate value, etc.). Figure 2 As shown, the method may further include the following steps: Step S210: Extract the parser state, parser operator, parser state transition and parser state key for each ParserState node in the IR node, and generate the JSON representation of the state node state. Step S220: Iterate through the JSON representation of the state node state to obtain the corresponding hardware machine instructions and generate the Parserstate machine code. Step S230: After completing the state of all user programs, dynamically create a checksum state as the last state of the parser based on whether the user has defined a checksum verification process, so as to execute the calculation of the checksum algorithm specified by the user and generate the Parser Checksum machine code.

[0038] The checksum algorithm includes at least one of csum16, crc16, and crc32.

[0039] In practical applications, for the generation of Parser machine code, for each parser->states (IR::ParserState node), a JSON representation of the state is generated, and then the corresponding hardware machine instructions are generated by traversing the JSON representation of the state. For example, the specific compilation algorithm is as follows: As an optional implementation method, for JSON generation: for each state in parser->states: state = json->add_parser_state / / Extract parser state; state->components = json->add_parser_op / / Extract the parser operator; json->add_parser_transition / / Extracts the parser state transition; json->add_parser_transition_key / / Extract parser state key.

[0040] The method for generating Parser machine code can specifically include the following steps: Step S1: Iterate through each state in the parser. For each component in each state, determine its operation type. If it is an extract operation, proceed to step S2. If it is an extract_VL operation, proceed to step S3. If it is an advance operation, proceed to step S4. If it is a field assignment or copy operation, proceed to step S5. If it is a primitive, proceed to step S6. Step S2: For each field in the header, perform fixed-length extraction, reducing the field to an extraction instruction sequence, which includes instructions such as XCT and MDF; if the field is a matching field for a state transition, reduce the state transition to an NXTH instruction, and configure the target state and field width. Step S3: Perform variable-length extraction, reducing the field to an extraction instruction sequence, which includes instructions such as SHFT and MDF; if the field is a matching field for state transition, reduce the state transition to an NXTH instruction and configure the target state and field width; Step S4: Degrade the advance operation to a SHFT instruction, only offset the packet header pointer, and do not write to PHV; where PHV refers to Packet Header Vector, which is a contiguous memory area that stores the field values ​​and metadata extracted by the parser. Step S5: Degrade field assignment or copy operations to MDF instructions; Step S6: Based on the primitive type, reduce it to the corresponding instruction: reduce field modification / copy primitives to MDF, COPY, and MOV instructions; reduce add_header primitives to MDF instructions to set header validity flags; reduce remove_header primitives to MDF instructions to clear header validity flags; reduce push primitives to stack operation instructions to push headers onto the front of the stack; reduce pop primitives to stack operation instructions to pop headers from the front of the stack. Step S7: After completing all user program states, the compiler automatically creates a checksum state as the last state of the parser, used to calculate the checksum algorithm, which includes CSUM16, CRC16, and CRC32. Based on the checksum calculation type, it is reduced to the corresponding instruction sequence: if the user specifies CSUM16, it is reduced to CSUM instructions; if the user specifies CSUM16, it is reduced to HCSUM instructions; if the user specifies CRC16, it is reduced to HCRC16 instructions; if the user specifies CRC32, it is reduced to HCRC32 instructions. Subsequently, a LAST instruction is generated to indicate calculation completion, a synchronization instruction is generated to wait for calculation completion, and a copy instruction is generated to write the result to the target field.

[0041] Its execution is as follows: For each state in states: for each statement in state->components: / / Generate the corresponding parser instructions based on the statement operation type: if (the operation is extract): For each field in the header: Fixed-length extraction generates a sequence of field extraction instructions (including XCT, MDF, and other instructions). if (field is the matching field for state transition): Generate the state transition instruction NXTH (configure the target state and field width); else if (the operation is extract_VL): Variable-length extraction generates a sequence of field extraction instructions (including SHFT, MDF, etc.). if (field is the matching field for state transition): Generate the state transition instruction NXTH (configure the target state and field width); else if (the operation is advance): The SHFT command is generated, which only offsets the message header pointer and does not write to the PHV. else if (the operation is a field assignment or copy): Generate assignment instruction MDF; else if (the operation is a primitive): Generate corresponding instructions based on primitive type: Field modification / copy operations → Generate MDF / COPY / MOV instructions; add_header → Generate MDF instructions (set header validity flags); remove_header → Generate MDF instructions (remove header validity flags); push → Generates a stack operation instruction (the header is pushed onto the front of the stack); pop → Generate stack operation instruction (pop the header from the front of the stack).

[0042] PHV refers to Packet Header Vector, a contiguous memory area that stores field values ​​and metadata extracted by the parser.

[0043] For the generation of Parser Checksum machine code, after completing all user program states, the compiler automatically creates a checksum state as the parser's last state, used to implement checksum algorithms, such as CSUM16 / CRC16 / CRC32 calculations. For example, the algorithm is as follows: Create a checksum state as the last state of the parser, and generate the corresponding instruction sequence based on the checksum calculation type: If the user specifies the csum16 algorithm, it drops to the CSUM instruction; If the user specifies the csum16 algorithm, it will be downgraded to the HCSUM instruction; If the user specifies the CRC16 algorithm, it will be reduced to an HCRC16 instruction sequence; If the user specifies the CRC32 algorithm, it will decrease to an HCRC32 instruction sequence; Generate LAST instructions (indicating calculation complete); Generate synchronization instructions (wait for calculation to complete); Generate a copy instruction (write the result to the target field).

[0044] In an alternative implementation, the above scheme can further incorporate multi-algorithm adaptive selection logic, i.e., automatically matching the verification strategy based on the data packet type. As an example, in the process of dynamically creating the checksum state, this method may further include the following steps: Step 1: Parse the packet header fields in the Parser state machine to extract the protocol type identifier; Step 2: Establish a mapping table between protocol types and verification algorithms, where: Ethernet frames are mapped to the CSUMI16 algorithm; IPv4 packets are mapped to the CRC16 algorithm; and IPv6 packets are mapped to the CRC32 algorithm. Step 3: Query the mapping table according to the protocol type identifier, and dynamically load the corresponding verification algorithm into the hardware programmable computing unit; Step 4: Perform checksum calculation through the hardware programmable computing unit and write the result into the data packet metadata field.

[0045] By automatically identifying protocol types through parsing packet header fields (such as EtherType / IP Version), protocol awareness is enhanced. A protocol-to-algorithm mapping table (non-fixed binding) is established during dynamic algorithm loading, supporting the expansion of new protocol-algorithm pairs. Furthermore, hardware can be co-designed, utilizing programmable computing units for hot algorithm loading, avoiding hardware reconfiguration. Moreover, the optimal verification algorithm is matched to different protocol characteristics (e.g., CRC32 for long IPv6 packets), optimizing computational resources. Therefore, this solution improves verification calculation efficiency and reduces hardware resource consumption in actual testing.

[0046] For generating MAT machine code, the IR:P4Action node is traversed to generate the JSON representation of the action, and then the machine instructions of the MAT unit are generated based on the JSON conversion. The compilation algorithm is as follows: For JSON generation: For each action in actions: actions_js = json->add_action / / Convert IR::P4Action to generate a JSON representation; For the generation of Mat machine code: Step S11: Iterate through each action statement in the action collection, determine its statement type, and execute step S12 if it is a field assignment statement, execute step S13 if it is an extern method call, execute step S14 if it is a conditional branch statement, and execute step S15 if it is an exit statement. Step S12: Based on the source operand type and field length, reduce the field assignment operation to the corresponding machine instruction: reduce immediate value assignment to MOV instruction sequence, where for fields with a length of no more than 4 bytes, it is reduced to a single MOV instruction, and for fields with a length of more than 4 bytes, it is reduced to multiple MOV instructions, each processing a maximum of 4 bytes; reduce RuntimeData to MOV instructions in AD mode; reduce inter-field copying of PHV field source to COPY instructions; reduce metadata assignment to MOV or COPY instructions; reduce bitwise operations to instructions such as SLL, SRL, CMUX, BSET, BCLR, BNOT, etc.; reduce arithmetic expressions to instructions such as ADD, SUB, etc.; reduce logical expressions to instructions such as XOR, AND, NAND, OR, NXOR, NOT, LAND, LOR, BEQ, BNE, BGT, BLTLT, BGE, BLE, etc. Step S13: Based on the type of the extern object, reduce the extern method call to the corresponding hardware instruction: reduce the Hash object to the HASH instruction, where the hash algorithm type includes CRC32, CRC16, XOR16, and CSUM16; reduce the Counter object to the COUNTER instruction; reduce the Meter object to the METER instruction. Step S14: Process conditional branch statements: First, assign a unique label to each target position of the conditional branch; then generate conditional jump instructions, which jump to the else branch or the end of the conditional statement when the condition is false; recursively process the statements in the then branch, descending them to the corresponding instructions; if an else branch exists, generate an unconditional jump instruction to jump to the end of the conditional statement, and recursively process the statements in the else branch; after all instructions are generated, backfill the target addresses of each jump instruction. Step S15: Process the exit statement: Generate an exit instruction to terminate message processing early; if the current exit statement is within a conditional branch, append a jump instruction to jump to the end of the action; otherwise, terminate the generation of subsequent instructions.

[0047] Its execution is as follows: for each action in actions_js: if (action is a field assignment): Generate instructions based on the source operand type and field length: Immediate value assignment → Generating MOV instruction sequence; For fields with a length ≤ 4 bytes: generate a single MOV instruction; For fields longer than 4 bytes: generate multiple MOV instructions (each up to 4 bytes); Runtime Data → Generate MOV instructions (AD mode); Copy PHV field source (inter-field copy) → Generate COPY command (PHV field copy); Metadata assignment → Generating MOV / COPY instructions; Bitwise operations → instructions such as SLL / SRL / CMUX / BSET / BCLR / BNOT; Arithmetic expressions → Generate ADD / SUB and other instructions; Logical expression generation (XOR / AND / NAND / OR / NXOR / NOT / LAND / LOR / ) BEQ / BNE / BGT / BLTLT / BGE / BLE) and other instructions; else if (statement is an extern method call): Generate instructions based on the extern object type: Hash object → Generate HASH instructions; Configure the hash_algorithm field (supported algorithm types: CRC32 / CRC16 / XOR16 / CSUM16); Counter object → Generate COUNTER instruction; Configure the counter_id field (counter index); Meter object → Generate METER instructions; Configure the meter_id field (flow meter index); else if (statement is an if conditional branch): Assign a unique label to each target location in the conditional branch; Generate conditional jump instructions: When the condition is false, jump to the else branch or the end of the if statement; Recursively process the statements in the then branch (generating corresponding instructions); if (an else branch exists): Generate an unconditional jump instruction (jump to the end of the if statement); Statements that recursively process the else branch; After the instructions are generated, the target addresses of each jump instruction are filled in. else if (statement is an exit statement): Generate an exit command (to prematurely terminate message processing); if (within the conditional branch): Add a jump instruction (jump to the end of the action); else: Terminate the generation of subsequent instructions.

[0048] In an alternative implementation, the method may further include the following steps: traversing each P4Control node in the IR nodes, converting the P4 Control node into a JSON representation of the Control node; the Control type of the Control node is Deparser; converting the JSON representation of the Control node into machine code to generate Deparser machine code.

[0049] For generating Deparser machine code, the IR:P4Control node (control type is deparser) is traversed, converted into JSON representation, and then the JSON is converted into intelligent machine code. The specific compilation algorithm is as follows: Step S21: Checksum Calculation: Iterate through each update_checksum or update_crc operation, and reduce it to the corresponding instruction sequence according to the algorithm type: Iterate through the input field list and reduce it to DEPAR_OP_CSUM, DEPAR_OP_CRC16, or DEPAR_OP_CRC32 instructions; then generate the DEPAR_OP_NOP instruction and wait for the calculation to complete; generate the DEPAR_OP_COPY instruction to copy the result from calc_result to the target field; generate the instruction to clear the calc_result value to prepare for the next calculation; Step S22: Send metadata: Generate a metadata length field assignment instruction to indicate the length of the message to be sent; generate a DEPAR_OP_SNDM instruction to send the metadata to the hardware metadata bus; Step S23: Header Sending: Iterate through each header in the deparser. If the operation is emit and the parameter is header, perform the following operations in sequence: First, generate a DEPAR_OP_JUMP instruction to perform a validity check, checking the offset of the valid flag bit of the header in the PHV. If valid is 0, skip the subsequent SNDH instructions. Then, generate a DEPAR_OP_SNDH instruction to send the header, where src_slct is configured as SRC_SLCT_FROM_PHV, offset is configured as the starting offset of the header in the PHV, and length is configured as the byte length of the header. Optionally, a DEPAR_OP_MASK instruction is generated for field masking. Step S24: Send payload: Generate DEPAR_OP_SNDP instruction to send the original message payload, and configure off_ctrl and len_ctrl to control the offset and length source; Step S25: Mark deparser processing as complete: Append the DEPAR_OP_END instruction.

[0050] JSON generation: structure->deparsers = json->add_deparser / / Convert JSON representation from IR::P4Control; Deparser machine code generation: / / 1. Checksum calculation; for each update_checksum / update_crc operation: Generate instruction sequences based on algorithm type: Iterate through the list of input fields to generate DEPAR_OP_CSUM / CRC16 / CRC32 instructions; Generate DEPAR_OP_NOP instructions (wait for calculation to complete); Generate the DEPAR_OP_COPY instruction (copy the result from calc_result to the target field); Generates a command to clear the calc_result value (in preparation for the next calculation).

[0051] / / 2. Send metadata; Generate a metadata length field assignment instruction (indicating the length of the message to be sent); Generate DEPAR_OP_SNDM instruction (send metadata to the hardware metadata bus). / / 3. Header sends instructions (core: validity check + sending); for each header in structure->deparsers: if (op == "emit" && parameter is header): a. Generate DEPAR_OP_JUMP instructions (validity check); Check the offset of the header's valid flag in the PHV; if (valid == 0): Skip subsequent SNDH instructions; b. Generate the DEPAR_OP_SNDH instruction (send header); Configure src_slct = SRC_SLCT_FROM_PHV; Configure the offset to be the starting offset of the header in the PHV; Configure length to the length of the header in bytes; c. Generate DEPAR_OP_MASK instructions (optional, used for field masks).

[0052] / / 4. Send payload: Generate the DEPAR_OP_SNDP instruction (send the raw message payload); Configure off_ctrl and len_ctrl (to control the source of offset / length); / / 5. Mark the deparser as complete: Finally, add the DEPAR_OP_END instruction.

[0053] Step S140: Based on the semantics of the P4 program, generate dedicated machine code firmware files for the network card hardware units corresponding to the parser, matching execution unit MAT, and deparser, respectively, to obtain the IR downcompilation result of the P4 program IR to hardware machine code.

[0054] Based on the relevant P4 program semantics described in the JSON, generate machine code for the three hardware units: Parser, MAT, and Deparser. Output the complete firmware file.

[0055] 1. P4 program IR to smart hardware machine code IR downcompilation method: The IR output from the P4C middleware describes target-independent program semantics. This invention lowers it down to the dedicated machine code of the three hardware units of the smart network interface card. Here, "Lowering" is a compiler term referring to the compilation process of converting high-level IR into low-level machine code. In this embodiment, the P4 JSON IR from the open-source P4C ecosystem is used as input. A lowering compilation method from P4 program IR to hardware machine code supports compiling general-purpose P4 programs into dedicated machine code firmware for smart network cards. This provides a method for compiling P4 program IR lowering into the machine code of three hardware units: parser, MAT, and deparser for smart network cards. In other words, it is a complete method for compiling general-purpose P4 language into executable machine code firmware for smart P4 processors. This implements a P4C compiler backend, enabling the compilation of programs written in P4 language into firmware for smart network cards. This allows for programming smart network cards using P4 language, closely aligning with the P4 processor's hardware resources for deep optimization of network protocols and improved performance.

[0056] In some embodiments, the network interface card's Parser and MAT are both matched through table entries, and the types and specifications of the table entries include TCAM, HASH, and CACHE; the method may also include the following steps: The Parser state is converted into TCAM table entries to generate results, and the transitionselect related data of P4 Parser is converted into Parser TCAM table entries; Convert the match type of the P4 table to a TCAM table entry, where the match type includes at least one of exact, ternary, lpm, and optional; Convert the exact match of the P4 table into a HASH table entry or a CACHE hardware table entry. The allocation of resources for the corresponding entries in the TCAM, HASH, and CACHE hardware tables is automatically determined by the compiler based on the resource consumption of the application.

[0057] TCAM refers to Ternary Content Addressable Memory, a hardware matching unit that supports three states: exact 0, exact 1, or any (don't-care) state. HASH refers to a hardware entry type based on a hash algorithm, supporting only exact matching. CACHE refers to a hardware entry type based on a caching mechanism, also supporting only exact matching. Matching type refers to the matching methods supported by the P4 table, including exact matching, ternary matching, lpm (longest prefix matching), and optional matching. A unified compilation method for P4 program table entries to intelligent heterogeneous hardware table entries is also included.

[0058] For table entry compilation: Both the parser and MAT of the smart network card use table entries for matching, but the table entry types and specifications are different (TCAM, HASH, CACHE, etc.). This invention adopts a unified compilation method to handle this.

[0059] For the generation of Parser state into TCAM table entries, the transition select information of P4 parser is converted into intelligent Parser TCAM table entries. For example, the specific compilation algorithm is as follows: Step S31: Traverse each transition in the current state. If the width of the matching field is greater than 8 bits, reverse the byte order of the matching value and the mask to adapt to the hardware little-endian format. Step S32: Convert the binary data / mask into a tri-state TCAM entry: Iterate through each bit of the matching field. If the bit is 0 in the mask, set the corresponding bit of the TCAM entry to X, i.e., wildcard (don't care); if the bit is 1 in both the mask and the value, set the corresponding bit of the TCAM entry to 1, i.e., exact match 1; if the bit is 1 in both the mask and the value, set the corresponding bit of the TCAM entry to 0, i.e., exact match 0. Step S33: Record the next state after the entry is successfully matched; Step S34: Fill the current state with 32 entries. If there are fewer than 32 entries, fill with all X entries.

[0060] Its execution is as follows: for each transition in state->transitions: / / Step 1: Byte order processing (hardware little-endian format adaptation); if (matching field width > 8 bits): Perform byte order reversal on the matched value and mask; / / Step 2: Convert binary (data / mask) into tri-state TCAM entry; for each bit in the matching field: if (this bit is 0 in the mask): Set the corresponding bit of the TCAM entry to X (wildcard, don't care); else if (the bit is 1 in the value): Set the corresponding bit of the TCAM entry to 1 (exact match 1); else: Set the corresponding bit of the TCAM entry to 0 (exact match 0); / / Step 3: Get and record the next state; Record the next state after a successful match for this entry; / / Step 4: Complete the current state entry to 32; while (entries<32): add all X entries.

[0061] For MAT entries, the matching type of the P4 table (exact / ternary / lpm / optional) is converted into a smart TCAM entry. For example, the specific compilation algorithm is as follows: Step S41: Iterate through all tables in the control. For each table_entry in each table, iterate through each key_element within that entry and convert it to the corresponding data and mask values ​​according to the matching type: If the matching type is exact, the mask is set to all 1s, meaning all bits match exactly, and the data is the key value of that entry; if the matching type is lpm, the high prefix_len bits of the mask are set to 1 and the remaining bits are set to 0 according to the prefix_len specified in the entry, and the data is the key value of that entry, where the first prefix_len bits are valid; if the matching type is ternary, the mask is taken from the mask field in the entry, supporting wildcards of any number of bits, and the data is the key value of that entry; if the matching type is optional and the entry provides a value, the mask is set to all 1s, and the data is the key value of that entry; if the entry does not provide a value, the mask is set to all 0s, meaning a complete wildcard match of all values, and the data is set to 0. Step S42: Encode the binary data / mask into a tri-state TCAM entry: Traverse each bit from bit 0 to bit total_bits-1. If the corresponding bit of the mask is 0, set the corresponding bit of tcam_entry to BIT_X, i.e., wildcard; if the corresponding bit of the mask is 1 and the corresponding bit of the data is 1, set the corresponding bit of tcam_entry to BIT_1, i.e., exact match 1; if the corresponding bit of the mask is 1 and the corresponding bit of the data is 0, set the corresponding bit of tcam_entry to BIT_0, i.e., exact match 0. Step S43: Convert the tri-state TCAM entry into the TCAM hardware data / mask format: Iterate through each bit from bit 0 to bit total_bits-1. If the corresponding bit of tcam_entry is BIT_1, then set the corresponding bit of tcam_data to 1 and the corresponding bit of tcam_mask to 1; if the corresponding bit of tcam_entry is BIT_0, then set the corresponding bit of tcam_data to 0 and the corresponding bit of tcam_mask to 1; if the corresponding bit of tcam_entry is BIT_X, then set the corresponding bit of tcam_data to 0 and the corresponding bit of tcam_mask to 0.

[0062] Its execution is as follows: For each table in control->tables: / / , iterate through all tables; For each table_entry in table->entries: / / , iterate through the entries in the table; for each key_element in table->key->keyElements: / / Iterate through the keys in the entry; if (match_type == "exact"): mask = all 1s (exact match of all bits); data = the key value of entry; else if (match_type == "lpm"): prefix_len = the prefix length specified in entry; mask = set the high prefix_len bit to 1 and the rest of the bits to 0; data = the key value of entry (the first prefix_len bits are valid); else if (match_type == "ternary"): mask = the mask field in entry (supports wildcards of any number of bits). data = the key value in the entry; else if (match_type == "optional"): if (entry provides a value): mask = all 1s (exact match for this value); data = the key value of entry; else: mask = all zeros (complete wildcard, matches all values); data = 0; / / Binary (data / mask) → Tri-state TCAM entry encoding; for i from 0 to total_bits-1: if (mask[i] == 0): tcam_entry[i] = BIT_X / / don't care (wildcard); else if (data[i] == 1): tcam_entry[i] = BIT_1 / / Exact match 1; else: tcam_entry[i] = BIT_0 / / Matches exactly 0.

[0063] / / Tri-state bits → TCAM hardware data / mask format; for i from 0 to total_bits-1: if (tcam_entry[i] == BIT_1): tcam_data[i] = 1, tcam_mask[i]= 1; else if (tcam_entry[i] == BIT_0): tcam_data[i] = 0, tcam_mask[i]= 1; else: / / BIT_X; tcam_data[i] = 0, tcam_mask[i]= 0.

[0064] In addition to the TCAM table, exact matches in the P4 table can also be converted into hash or cache hardware table entries. Unlike the TCAM table, hash and cache tables only support exact matches. The conversion algorithm is as follows: data = table->key->keyElements.

[0065] In this embodiment of the application, a method is provided to compile parser state transitions and MAT table matching keys in the P4 program into heterogeneous hardware table entries (TCAM / HASH / CACHE), which realizes that the allocation of the three table entry resources is automatically allocated by the compiler according to the resource consumption of the application.

[0066] As an optional implementation, the above scheme can also incorporate machine learning models to predict traffic characteristics and dynamically adjust the table entry allocation strategy. For example, in the process of allocating the above table entry resources, this method may further include the following steps: Step S51: Collect historical traffic characteristic data in real time during the compiler runtime phase. The traffic characteristic data includes packet length distribution, protocol type ratio, and flow table matching hit rate. Step S52: Construct a lightweight machine learning prediction model, using the Time Series Analysis Algorithm (ARIMA) and a Random Forest classifier to jointly train the traffic features; Step S53: Dynamically adjust the entry allocation strategy based on the traffic trend results output by the prediction model, wherein: when the predicted LPM matching ratio is greater than a set threshold (e.g., >60%), increase the TCAM resource allocation weight by a set percentage (e.g., 70%); when a short-flow burst is detected (e.g., flow rate >10K per second), increase the CACHE entry capacity by a set percentage (e.g., 50%); if the stability of the Exact matching flow is higher than a set threshold, enable Hash entry merging optimization. Step S54: Write the optimized entry allocation strategy into the hardware configuration register and update the machine code generation logic of the MAT unit in real time.

[0067] A closed-loop "monitoring-prediction-adjustment" mechanism dynamically couples resource allocation with traffic characteristics, achieving a closed-loop adaptive system. For the hardware coordination mechanism, prediction results are directly written to hardware registers to drive machine code reconstruction (not software recompilation), reducing TCAM resource waste, lowering hash table collision rates, and thus improving resource utilization. Furthermore, by combining ARIMA with a random forest model, the system exhibits low memory consumption and low latency in a compiler environment, achieving a lightweight design.

[0068] For example, the process of constructing a lightweight machine learning prediction model in step S52 above, using the Time Series Analysis Algorithm (ARIMA) and a Random Forest classifier to jointly train traffic features, can be achieved through the following formula:

[0069] in, This represents the final predicted value, that is, the traffic trend prediction value finally output by the fusion model at time point t; This refers to the final random forest model, which is the final model obtained after joint training. Its training data includes not only the original features. It also includes the ARIMA model's prediction for each sample; This represents the ARIMA model prediction, which is the initial prediction given by the ARIMA model at time point t. This prediction is then input into the random forest model as a new feature. Other features, besides ARIMA predictions, include other features used for training the random forest model, such as packet length distribution, protocol type ratio, flow table match hit rate, and other historical statistics.

[0070] In this embodiment, the ARIMA model first captures the time-series trend (such as linear growth or periodic fluctuations) from historical data, and then uses this trend information as an expert opinion (i.e., This information is provided to the random forest model. The random forest then combines features from other dimensions (such as...) Learn how to best utilize this expert opinion to make a final, more accurate judgment.

[0071] In one embodiment, the P4 processor's pipeline is determined by the Tuna architecture model, which abstracts the P4 processor's core hardware data into APIs. The core architecture of the Tuna architecture model includes an ingress pipeline package (IngressPipeline), an encapsulated exit pipeline package (EgressPipeline), and a top-level architecture definition package (TunaNic). The IngressPipeline package contains programmable blocks for IngressParser, VerifyChecksum, Ingress Control, ComputeChecksum, and IngressDeparser, used to support two types of metadata parameterization: recirculating metadata (RECIRCM) and inter-pipeline metadata (NM). The EgressPipeline package contains programmable blocks for EgressParser, VerifyChecksum, Egress Control, ComputeChecksum, and EgressDeparser. The TunaNic package contains IngressPipeline components, PacketReplicationEngine components, EgressPipeline components, and BufferingQueueingEngine components, used to form a complete network interface card (NIC) data plane.

[0072] For the Tuna architecture, the P4 programmable architecture model of the network interface card is defined in the tuna.p4 file, including the ingress and egress dual pipeline structure, the parser-control-deparser three-stage processing model, the hardware-specific metadata structure, and the extern object.

[0073] It should be noted that the Tuna architecture model defines the pipeline of the intelligent P4 processor, abstracting the core internals of the hardware into APIs. By inheriting this model, users can quickly program the Winghua smart network card.

[0074] The core architecture pipeline of the Tuna architecture model includes three layers of package definitions: The IngressPipeline package is the entry pipeline, consisting of five programmable blocks: IngressParser, VerifyChecksum, Ingress Control, ComputeChecksum, and IngressDeparser. It supports two types of metadata parameterization: RECIRCM (Recycled Metadata) and NM (Inter-pipeline Metadata Transfer). The EgressPipeline package encapsulates the exit pipeline and consists of five programmable blocks: EgressParser, VerifyChecksum, Egress Control, ComputeChecksum, and EgressDeparser. The TunaNic package defines the top-level architecture, combining four components—IngressPipeline, PacketReplicationEngine, EgressPipeline, and BufferingQueueingEngine—to form a complete network interface card (NIC) data plane. parser IngressParser<H, M, RECIRCM> ( packet_in buffer, out H parsed_hdr, inout M user_meta, in tuna_ingress_parser_input_metadata_t istd, in RECIRCM recirculate_meta); control VerifyChecksum<H, M> (inout H hdr, inout M meta); control Ingress<H, M> ( inout H hdr, inout M user_meta, intuna_ingress_input_metadata_tistd, inout tuna_ingress_output_metadata_t ostd); control ComputeChecksum<H, M> (inout H hdr, inout M meta); control IngressDeparser<H, M, RECIRCM, NM>( packet_out buffer, out RECIRCM recirculate_meta, out NM normal_meta, inout H hdr, in M meta, in tuna_ingress_output_metadata_t istd); parser EgressParser<H, M, NM>( packet_in buffer, out H parsed_hdr, inout M user_meta, in tuna_egress_parser_input_metadata_t istd, in NM normal_meta); control Egress<H, M>( inout H hdr, inout M user_meta, intuna_egress_input_metadata_tistd, inout tuna_egress_output_metadata_t ostd); control EgressDeparser<H, M, RECIRCM>( packet_out buffer, out RECIRCM recirculate_meta, inout H hdr, in M meta, in tuna_egress_output_metadata_t istd); package IngressPipeline<IH, IM, NM, RECIRCM>( IngressParser<IH, IM, RECIRCM> IP VerifyChecksum<IH, IM> vr, Ingress<IH, IM> ig, ComputeChecksum<IH, IM> ck, IngressDeparser<IH, IM, RECIRCM, NM> id); package EgressPipeline<EH, EM, NM, RECIRCM> ( EgressParser<EH, EM, NM> ep, VerifyChecksum<EH, EM> vr, Egress<EH, EM> e.g., ComputeChecksum<EH, EM> ck, EgressDeparser<EH, EM, RECIRCM> ed); package TunaNic<IH, IM, EH, EM, NM, RECIRCM> ( IngressPipeline<IH, IM, NM, RECIRCM> ingress, PacketReplicationEngine pre, EgressPipeline<EH, EM, NM, RECIRCM> egress, BufferingQueueingEngine (bqe) The Tuna architecture model also defines hardware-specific built-in metadata types: tuna_ingress_parser_input_metadata_t: Input metadata of the entry parser, containing a packet_path field of type TUNA_PacketPath_t; tuna_egress_parser_input_metadata_t: Input metadata for the egress parser, containing a packet_path field of type TUNA_PacketPath_t and an egress_port field of type PortId_t (virtual port ID); tuna_ingress_input_metadata_t: Read-only metadata input in the ingress Control phase, including fields such as packet_path, packet_length, checksum_success, ingress_port, and ingress_timestamp; tuna_egress_input_metadata_t: Read-only metadata input during the egress control phase, including fields such as packet_path, packet_length, checksum_success, egress_port (egress port), egress_timestamp (egress timestamp), instance (instance ID, from PacketReplicationEngine), and class_of_service (service level); tuna_ingress_output_metadata_t: Control metadata output during the ingress Control phase, used to specify the forwarding path and processing action of the packet, including fields such as len (packet length), drop (drop flag), multicast_group (multicast group ID), clone (clone flag), resubmit (resubmit flag), port (port ID), and class_of_service (service level); tuna_egress_output_metadata_t: Control metadata output during the exit Control phase, including fields such as len, drop, multicast_group, clone, resubmit, port, and class_of_service.

[0075] In this embodiment, a P4 programmable architecture model (Tuna architecture) for dedicated smart network interface cards is implemented, which includes a dual pipeline structure, hardware-specific metadata types, and cross-pipeline data transfer mechanism.

[0076] In some instances, the Tuna architecture model includes a hardware-supported hash algorithm enumeration `HashAlgorithm` for the P4 processor, as well as several external extension functions for calculating the checksum `csum`. The hash algorithm enumeration `HashAlgorithm` includes: checksum `csum`, `crc16`, `crc32`, Tuna-custom CRC32, `xor4`, `xor8`, `xor16`, `xor32`, and Toeplitz hash. The multiple external extension functions include the `verify_checksum` function, the `update_checksum` function, the `verify_checksum_with_payload` function, and the `update_checksum_with_payload` function.

[0077] The Tuna architecture model defines a hardware-supported hash algorithm enumeration: csum (checksum), crc16, crc32 (standard CRC32), crc32_1edc6f41 (Tuna custom CRC32), xor4, xor8, xor16, xor32, and toeplitz (Toeplitz hash), as well as four external extension extern functions for checksum calculation: verify_checksum, update_checksum, verify_checksum_with_payload, and update_checksum_with_payload.

[0078] enum HashAlgorithm { csum, / / for checksum crc16, / / for checksum crc32, / / Standard CRC32 (polynomial 0x04c11db7) crc32_1edc6f41, / / Tuna custom CRC32 (polynomial 0x1edc6f41) xor4, xor8, xor16, xor32, toeplitz / / toeplitz hash } extern Hash <o>{ Hash(HashAlgorithm algo); O get_hash <d>(in D data); } The Tuna architecture model, through the above definition, abstracts the hardware characteristics of smart network cards (dual pipelines, recirculation mechanism, multiple destination routing, caching mechanism, packet replication) into a P4 programmable interface, enabling P4 programs to fully utilize hardware capabilities. Once the model file is included by the application, it can inherit the relevant APIs and be compiled into the firmware when the relevant application is compiled.

[0079] Figure 3 A schematic diagram of the structure of a compilation system based on the P4C compiler backend is provided. For example... Figure 3 As shown, the compilation system 300 based on the P4C compiler backend includes: The acquisition module 301 is used to acquire an API library containing the P4C front-end and mid-end, and to obtain the IR node after P4C mid-end processing through the API library; The conversion module 302 is used to convert the semantic description data of the IR node into JSON format data based on the IR node processed by the P4C mid-end, and use the JSON format data as the input of the P4 runtime. Parsing module 303 is used to traverse the JSON format data and parse the P4 program semantics described in the JSON format data respectively; wherein, the P4 program semantics includes at least one of the following: Parser state machine, action operation, control pipeline, Deparser sending sequence, external extension extern object instance, and checksum; The generation module 304 is used to generate dedicated machine code firmware files for the network card hardware units corresponding to the parser, matching execution unit MAT, and deparser based on the semantics of the P4 program, so as to obtain the IR downcompilation result of the P4 program IR to hardware machine code.

[0080] The compilation system based on the P4C compiler backend provided in this application embodiment has the same technical features as the compilation method based on the P4C compiler backend provided in the above embodiments, so it can also solve the same technical problems and achieve the same technical effects.

[0081] An electronic device provided in this application embodiment, such as Figure 4 As shown, the electronic device 400 includes a processor 402 and a memory 401. The memory stores a computer program that can run on the processor. When the processor executes the computer program, it implements the steps of the method provided in the above embodiments.

[0082] See Figure 4 The electronic device also includes a bus 403 and a communication interface 404. The processor 402, the communication interface 404 and the memory 401 are connected via the bus 403. The processor 402 is used to execute executable modules, such as computer programs, stored in the memory 401.

[0083] The memory 401 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 404 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network.

[0084] Bus 403 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0085] The memory 401 is used to store programs. After receiving an execution instruction, the processor 402 executes the program. The method executed by the system defined by the process disclosed in any of the preceding embodiments of this application can be applied to the processor 402 or implemented by the processor 402.

[0086] Processor 402 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 402 or by instructions in software form. The processor 402 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be 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 manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 401, and processor 402 reads the information from memory 401 and, in conjunction with its hardware, completes the steps of the above method.

[0087] Corresponding to the above-described compilation method based on the P4C compiler backend, this application embodiment also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions cause the processor to perform the steps of the above-described compilation method based on the P4C compiler backend.

[0088] The compilation system based on the P4C compiler backend provided in this application embodiment can be specific hardware on the device or software or firmware installed on the device. The system provided in this application embodiment has the same implementation principle and technical effects as the aforementioned method embodiments. For the sake of brevity, any parts not mentioned in the system embodiment section can be referred to the corresponding content in the aforementioned method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

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

[0090] For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

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

[0092] In addition, the functional units in the embodiments provided in 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.

[0093] 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 compilation method based on the P4C compiler backend 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.

[0094] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0095] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.< / d> < / o>

Claims

1. A compilation method based on the P4C compiler backend, characterized in that, The method includes: Obtain the application programming interface (API) library containing the P4C front-end and mid-end, and obtain the IR node after P4C mid-end processing through the API library; Based on the IR node processed by the P4C, the semantic description data of the IR node is converted into JSON format data, and the JSON format data is used as the input of P4 runtime; The JSON format data is traversed and the P4 program semantics described in the JSON format data are parsed respectively; wherein, the P4 program semantics includes at least one of parser state machine, action operation, control pipeline, inverse parser sending sequence, external extension object instance and checksum; Based on the P4 program semantics, dedicated machine code firmware files for the network card hardware units corresponding to the parser, matching execution unit, and inverse parser are generated respectively, resulting in the IR downcompilation compilation result of the P4 program IR to the hardware machine code.

2. The method according to claim 1, characterized in that, Also includes: For each parser state node in the IR node, extract the parser state, parser operator, parser state transition, and parser state key value to generate a JSON representation of the state node. Iterate through the JSON representation results of the state nodes to obtain the corresponding hardware machine instructions and generate parser state machine codes; After completing the states of all user programs, a checksum state is dynamically created as the last state of the parser based on whether the user has defined a checksum and verification process, so as to execute the calculation of the user-specified checksum algorithm and generate the parser checksum machine code; the calculation of the checksum algorithm includes at least one of CSUM16, CRC16 and CRC32.

3. The method according to claim 1, characterized in that, Also includes: Iterate through each P4 action node in the IR nodes and generate a JSON representation of the action node; The JSON representation of the action node is converted into machine instructions of the MAT unit to generate MAT machine code.

4. The method according to claim 1, characterized in that, Also includes: Iterate through each P4 control node in the IR nodes and convert the result of the P4 control node into a JSON representation of the control node. The control type of the control node is an inverse parser; The JSON representation of the control node is converted into machine code to generate the machine code for the inverse parser.

5. The method according to claim 2, characterized in that, Also includes: Both the network card's resolver and MAT are matched through table entries, the types and specifications of which include TCAM, HASH and CACHE; The method further includes: The parser state is converted into TCAM entry generation results, and the transition selection related data of the P4 parser is converted into parser TCAM entries; Convert the matching type of the P4 data table into a TCAM table entry, wherein the matching type includes at least one of the following: exact match, ternary match, longest prefix match, and optional match; Convert an exact match of the P4 data table into a HASH entry or a CACHE hardware entry. The allocation of resources for the corresponding entries in the TCAM table, the HASH table, and the CACHE hardware table is automatically determined by the compiler based on the resource consumption of the application.

6. The method according to claim 1, characterized in that, The pipeline of the P4 processor is determined by the TUNA architecture model, which is used to abstract the hardware core data of the P4 processor into APIs. The core architecture of the TUNA architecture model includes an inlet pipeline, an outlet pipeline, and the top-level architecture definition TUNANIC package; The ingress pipeline contains an ingress parser, checksum verification, ingress control, checksum calculation, and a programmable block for the ingress parser, used to support two types of metadata parameterization: re-loop metadata RECIRCM and inter-pipeline metadata NM. The exit pipeline includes an exit parser, a checksum verification, an exit control, a checksum calculation, and a programmable block for the exit parser; The top-level architecture defines TUNANIC as including an ingress pipeline component, a packet copying engine component, an egress pipeline component, and a buffer queuing engine component, which are used to form a complete network interface card data plane.

7. The method according to claim 6, characterized in that, The TUNA architecture model includes hardware-supported hash algorithm enumeration and multiple external extension functions for checksum calculation of the P4 processor. The hash algorithm enumeration includes: CSUM, CRC16, CRC32, TUNA custom CRC32, XOR4, XOR8, XOR16, XOR32, and Toeplitz hash. The multiple external extension functions include a checksum function, an update checksum function, a payload checksum verification function, and a payload update checksum function.

8. A compilation system based on the P4C compiler backend, characterized in that, include: The acquisition module is used to acquire an API library containing the P4C front-end and mid-end, and to obtain the IR node after P4C mid-end processing through the API library; The conversion module is used to convert the semantic description data of the IR node after processing by the P4C into JSON format data, and use the JSON format data as input for P4 runtime. The parsing module is used to traverse the JSON format data and parse the P4 program semantics described in the JSON format data respectively; wherein, the P4 program semantics includes at least one of the following: parser state machine, action operation, control pipeline, reverse parser sending sequence, external extension object instance, and checksum; The generation module is used to generate dedicated machine code firmware files for the network card hardware units corresponding to the parser, the matching execution unit MAT, and the inverse parser based on the semantics of the P4 program, so as to obtain the IR downcompilation result of the P4 program IR to the hardware machine code.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images