Packet processing apparatus, packet processing method, and computer-readable storage medium

Abstract

The invention relates to a packet processing apparatus, a packet processing method, and a computer readable storage medium. A packet processing apparatus includes: a decoding circuit to decode a received packet processing instruction, where the packet processing instruction is to process a packet header; and a packet header register for storing a packet header.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to the field of packet processing, and in particular, to a packet processing device, a packet processing method, and a computer-readable storage medium. Background Art

[0002] Cloud and high-performance data centers constitute the key pillars of computing infrastructure and are growing at an unprecedented rate. Packet processing capability is the main performance target of data centers. Multi-core architectures of general-purpose network processors (NPs) have been proposed to cope with the growing demand for computing resources. Summary of the invention

[0003] One aspect of the present disclosure provides a packet processing device, comprising: a decoding circuit for decoding a received packet processing instruction, wherein the packet processing instruction is used to process a packet header; and a packet header register for storing the packet header.

[0004] In some embodiments, the packet processing instructions include one or more of: a packet header register load instruction, a packet header register store instruction, a packet header parsing instruction, and a packet header checksum instruction.

[0005] In some embodiments, the packet header register load instruction includes: a source register field for indicating a source register, wherein the source register stores memory address information related to the packet header; and an offset field for indicating an address offset related to the packet header.

[0006] In some embodiments, the device also includes: an execution circuit for executing a decoded packet header register load instruction to read the packet header from a memory address determined based on the memory address information and the address offset, and write the read packet header into the packet header register.

[0007] In some embodiments, the packet header register storage instruction includes: a packet header register index field, used to indicate the starting position of reading the packet header in the packet header register; a source register field, used to indicate a source register, wherein the source register stores memory address information related to the packet header; and an offset field, used to indicate an address offset related to the packet header.

[0008] In some embodiments, the apparatus further comprises: an execution circuit for executing the decoded packet header register store instruction to store bytes in the packet header register starting from the packet header register index into a memory address determined based on the memory address information and the address offset.

[0009] In some embodiments, the packet header parsing instruction includes: a function field, used to distinguish parsing instructions of different network protocols; a first source register field, used to indicate a first source register, wherein the first source register is used to select the type of packet header field to be extracted; a second source register field, used to indicate a second source register, wherein the second source register is used to specify a specific parsing operation; a destination register field, used to indicate a destination register, wherein the destination register is used to store the parsed field results; and a packet header register index field, used to indicate the starting position of reading the packet header in the packet header register.

[0010] In some embodiments, the apparatus further comprises: an execution circuit for executing the decoded packet header parsing instruction to read the field specified by the first source register field from the packet header register.

[0011] In some embodiments, the packet header checksum instruction includes: a source register field for indicating a source register, wherein the source register stores the byte length of the data to be processed; a destination register field for indicating a destination register, wherein the destination register is used to store a final checksum result; and a packet header register index field for indicating the starting position of reading the packet header in the packet header register.

[0012] In some embodiments, the apparatus further comprises: an execution circuit for executing the decoded packet header checksum instruction to read bytes of the byte length specified by the source register field from the packet header register, calculate a checksum for the read bytes, and store the calculated checksum result in the destination register.

[0013] One aspect of the present disclosure provides a packet processing method, comprising: decoding a received packet processing instruction, wherein the packet processing instruction is used to process a packet header; and executing the decoded packet processing instruction to process the packet header.

[0014] One aspect of the present disclosure provides a computer-readable storage medium having computer-executable instructions stored thereon, wherein the computer-executable instructions, when executed by a processing circuit, cause the processing circuit to perform the packet processing method as described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Embodiments of the present disclosure will be illustrated by way of example and not limitation in the accompanying drawings in which like reference numerals refer to similar elements.

[0016] Figure 1An example of computing hardware that processes instructions is illustrated.

[0017] Figure 2 A block diagram of an example processor and / or System on a Chip (SoC) is illustrated, which may have one or more cores and have an integrated memory controller.

[0018] Figure 3 An example of a run-to-completion (RTC) network processor architecture is illustrated.

[0019] Figure 4 An example of a core based on the von Neumann architecture is shown.

[0020] Figure 5 An example of encoding of a packed header register load or store instruction according to an embodiment of the present disclosure is illustrated.

[0021] Figure 6 An example of encoding of a packet header parsing instruction according to an embodiment of the present disclosure is illustrated.

[0022] Figure 7 An example of encoding of a packet header checksum instruction according to an embodiment of the present disclosure is illustrated.

[0023] Figure 8 A flowchart of a packet processing method according to some embodiments of the present disclosure is illustrated. DETAILED DESCRIPTION

[0024] The various aspects of the illustrative embodiments will be described using terms commonly used by those skilled in the art to convey the essence of the present disclosure to other persons skilled in the art. However, it will be apparent to those skilled in the art that many alternative embodiments may be implemented using the parts of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are provided to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to those skilled in the art that alternative embodiments may be implemented without these specific details. In other examples, known features may be omitted or simplified in order to avoid blurring the illustrative embodiments.

[0025] In addition, various operations are described as multiple discrete operations in sequence in a manner that is most helpful for understanding the illustrative embodiments; however, the order of description should not be interpreted as implying that these operations are necessarily order-dependent. In particular, these operations do not need to be performed in the order presented.

[0026] The phrases "in an embodiment," "in one embodiment," and "in some embodiments" are used repeatedly herein. These phrases generally do not refer to the same embodiment; however, they may refer to the same embodiment. Unless the context dictates otherwise, the terms "comprising," "having," and "including" are synonymous. The phrases "A or B" and "A / B" mean "(A), (B), or (A and B)."

[0027] Figure 1 An example of computing hardware for processing instructions is illustrated. According to some embodiments of the present disclosure, the instructions may include, but are not limited to, arithmetic instructions (e.g., addition (ADD) instructions, subtraction (SUB) instructions, etc.), and memory access instructions, such as memory access for register overflow (e.g., memory load (LOAD) or storage (STORE)) instructions. As shown in the figure, the storage device 103 stores instructions 101 to be executed.

[0028] Instruction 101 is received by decoder circuit 105. For example, decoder circuit 105 receives the instruction from a fetch circuit (not shown). The instruction may take any suitable format. In one example, the instruction includes fields for an opcode, (one or more) source identifiers, and a destination identifier. In some examples, the source and destination are registers, while in other examples, one or more of them are memory locations. In some examples, one or more of the sources may be immediate operands. In some examples, the opcode details one or more operations to be performed.

[0029] A more detailed example of at least one instruction format for the instruction will be described in detail later. Decoder circuit 105 decodes the instruction into one or more operations. In some examples, this decoding includes generating a plurality of micro-operations to be executed by execution circuitry (e.g., execution circuitry 109). Decoder circuit 105 also decodes instruction prefixes.

[0030] In some examples, register renaming, register allocation and / or scheduling circuitry 107 provides functionality for one or more of: 1) renaming logical operand values ​​to physical operand values ​​(e.g., a register alias table in some examples); 2) assigning status bits and flags to decoded instructions; and 3) scheduling decoded instructions from an instruction pool for execution by execution circuitry (e.g., using a reservation station in some examples).

[0031] Registers (register files) and / or memory 108 store data as operands of instructions, which are operated on by execution circuitry 109. Example register types include general purpose registers (GPRs), and floating point registers.

[0032] The execution circuit 109 executes the decoded instruction. Executing the decoded instruction causes the execution circuit to perform the corresponding operation. In some examples, the retirement / writeback circuit 111 architecturally commits the destination register to a register or memory 108 and retires the instruction.

[0033] An example of the format of an instruction is OPCODE DST, SRC1, SRC2. In some examples, OPCODE is the opcode mnemonic for the instruction, such as ADD, SUB, STORE, LOAD, etc. DST is a field for the destination operand, such as a packed data register or memory. SRC1 and SRC2 are fields for the source operand, such as a packed data register and / or memory.

[0034] Figure 2 A block diagram of an example processor and / or SoC 200 is illustrated, which may have one or more cores and have an integrated memory controller. The processor 200 illustrated by the solid line box has a single core 202(A), a system agent unit circuit 210, and a set of one or more interface controller unit circuits 216, while the optionally added dashed line box illustrates an alternative processor 200 as having multiple cores 202(A)-(N), a set of one or more integrated memory control unit circuits 214 in the system agent unit circuit 210, dedicated logic 208, and a set of one or more interface controller unit circuits 216. Note that the processor 200 may be one of a processor or a coprocessor.

[0035] Thus, different implementations of processor 200 may include: 1) a CPU, where dedicated logic 208 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 202 (A)-(N) are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, or a combination of the two); 2) a coprocessor, where cores 202 (A)-(N) are a large number of dedicated cores primarily for graphics and / or scientific (throughput) purposes; and 3) a coprocessor, where cores 202 (A)-(N) are a large number of general purpose in-order cores. Thus, processor 200 may be a general purpose processor, a coprocessor, or a special purpose processor, such as a network or communication processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit), a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. Processor 200 may be part of and / or may be implemented on one or more substrates using any of a variety of process technologies, such as complementary metal oxide semiconductor (CMOS), bipolar CMOS (BiCMOS), P-type metal oxide semiconductor (PMOS), or N-type metal oxide semiconductor (NMOS).

[0036] The memory hierarchy includes one or more levels of cache unit circuits 204(A)-(N) within the cores 202(A)-(N), a set of one or more shared cache unit circuits 206, and external memory (not shown) coupled to the set of integrated memory controller unit circuits 214. The set of one or more shared cache unit circuits 206 may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, such as last level cache (LLC), and / or combinations thereof. While in some examples an interface network circuit 212 (e.g., a ring interconnect) provides an interface to the dedicated logic 208 (e.g., integrated graphics logic), the set of shared cache unit circuits 206, and the system agent unit circuit 210, alternative examples use any number of well-known techniques to provide interfaces to these units. In some examples, coherency is maintained between one or more circuits in the shared cache unit circuits 206 and the cores 202(A)-(N). In some examples, interface controller unit circuitry 216 couples the cores 202 to one or more other devices 218 , such as one or more I / O devices, storage, one or more communication devices (eg, wireless network, wired network, etc.), and the like.

[0037] In some examples, one or more of the cores 202(A)-(N) have multi-threading capabilities. The system agent unit circuit 210 includes those components that coordinate and operate the cores 202(A)-(N). The system agent unit circuit 210 may include, for example, a power control unit (PCU) circuit and / or a display unit circuit (not shown). The PCU may be (or may include) logic and components required to regulate the power state of the cores 202(A)-(N) and / or the dedicated logic 208 (e.g., integrated graphics logic). The display unit circuit is used to drive one or more externally connected displays.

[0038] The cores 202(A)-(N) may be homogeneous with respect to instruction set architecture (ISA). Alternatively, the cores 202(A)-(N) may be heterogeneous with respect to ISA; that is, a subset of the cores 202(A)-(N) may be capable of executing one ISA, while other cores may be capable of executing only a subset of the ISA or may be capable of executing another ISA.

[0039] Figure 3 Figure 2 shows an example of a Run-to-Completion (RTC) network processor architecture. Figure 3As shown, a typical modern RTC network processor architecture usually operates in the following manner: after a packet enters the RTC network processor architecture, the packet is usually first processed by a packet distributor, and then the packet distributor dispatches the packet to an appropriate packet processing engine (Packet Processing Engine, PPE) for processing. The structure of the PPE is basically based on the standard von Neumann architecture core.

[0040] Figure 4 Figure 1 shows an example of a core based on the von Neumann architecture. Figure 3 The structure of the PPE in the network processor architecture shown is basically based on the standard von Neumann architecture core, including components such as instruction memory, data memory, registers, arithmetic logic unit (ALU) and program counter (PC), such as Figure 4 As shown. PPE is usually based on Reduced Instruction Set Computing (RISC) architecture or Microprocessor without interlocked pipeline stages (MIPS) core. Recently, research has focused on utilizing RISC-V cores for packet processing, which can be seen, for example, in the article entitled "A RISC-Vin-network accelerator for flexible high-performance low-power packetprocessing" published by Di Girolamo S, Kurth A, Calotoiu A, et al. in the 48th International Symposium on Computer Architecture (ISCA) of the Association for Computing Machinery (ACM) / Institute of Electrical and Electronics Engineers (IEEE), 2021 (see pages 958-971).

[0041] PPE based on RISC-V architecture can perform operations such as packet parsing, forwarding and flow control. No floating point, multiplication or division operations are required during packet processing. Only RISC-V I extension (i.e. integer extension of RISC-V, representing the basic integer instruction set of RISC-V) is sufficient. However, due to the specific characteristics of network processors, packet processing (e.g., protocol header parsing) involves complex operations and field extraction, which may require a large number of standard instructions to complete.

[0042] In view of the above problems, the present disclosure proposes a RISC-V-based network processing extension, which aims to accelerate the RISC-V-based network processor by simplifying instructions and reducing memory access. Specifically, the present disclosure proposes a new instruction extension in a RISC-V-based network processor based on the characteristics of packet processing, improves processing efficiency and execution speed, realizes specific acceleration for supporting network packet processing, and helps to create a better ecosystem for RISC-V network processors.

[0043] According to the embodiments of the present disclosure, in view of the characteristics of packet processing, a packet header register load or store instruction, a packet header parsing instruction, and a packet header checksum instruction are proposed. These instructions are described in detail below.

[0044] Packet header register load or store instructions Processing network protocols usually requires parsing multiple packet header fields (e.g., Ethernet, Internet Protocol (IP), User Datagram Protocol (UDP), Transmission Control Protocol (TCP) header fields, etc.), which usually involves a large number of cache memory access operations. Typically, the length of the cache line in the processor is 64 bytes or 128 bytes or even longer, which is longer than the length of the packet header (usually 20-60 bytes). Since the length of the packet header is usually smaller than the length of the cache line, in most cases, reading one cache line can obtain the entire packet header. However, if the starting position of the packet header is not aligned with the starting position of the cache line, it may be necessary to read two cache lines to obtain the entire packet header. Therefore, at most only two cache lines need to be read to obtain the entire packet header. After obtaining the entire packet header, any field in the packet header can be parsed.

[0045] According to an embodiment of the present disclosure, a dedicated packet header register (PHR) with a length of 64 bytes is proposed, and two memory access instructions are proposed, namely a packet header register load instruction and a packet header register store instruction, which can save a lot of RISC-V memory access instructions and register usage.

[0046] Figure 5 An example of encoding of a packed header register load or store instruction according to an embodiment of the present disclosure is illustrated.

[0047] like Figure 5 As shown, the packet header register load instruction according to an embodiment of the present disclosure may be encoded with a network processor (NP) operation code field, a first source register (rs1) field, a function field, and an offset field.

[0048] The NP opcode field may indicate a network processor instruction opcode. In one embodiment, bits 0 to 6 of a packet header register load instruction may be used to encode the NP opcode field, such as Figure 5 shown.

[0049] The rs1 field may indicate a first source register that may store memory address information associated with the packet header. In one embodiment, bits 7 to 11 of the packet header register load instruction may be used to encode the rs1 field, such as Figure 5 shown.

[0050] The function field may indicate the function or operation of the instruction (eg, load). In one embodiment, bits 12 to 14 of a packet header register load instruction may be used to encode the function field, such as Figure 5 As an example, bits 12 to 14 of the packet header register load instruction may be encoded as a fixed value 000 to indicate the load function, such as Figure 5 shown.

[0051] The offset field may indicate an address offset associated with the packet header. In one embodiment, bits 15 to 31 of the packet header register load instruction may be used to encode the offset field, such as Figure 5 shown.

[0052] According to some embodiments of the present disclosure, the packet header register load instruction may determine the memory address based on the rs1 field and the offset field to read the packet header from the memory address and write the read packet header into the PHR. Figure 5In the example shown, the packet header register load instruction may read 64 consecutive bytes from memory address x[rs1]+sign extension (offset) and write them into the PHR register.

[0053] like Figure 5 As shown, the packet header register store instruction according to an embodiment of the present disclosure may be encoded with an NP opcode field, a first source register (rs1) field, a PHR index (PHRidx) field, a function field, and an offset field.

[0054] The NP opcode field may indicate a network processor instruction opcode. In one embodiment, bits 0 to 6 of the packet header register storage instruction may be used to encode the NP opcode field, such as Figure 5 shown.

[0055] The rs1 field may indicate a first source register that may store memory address information associated with the packet header. In one embodiment, bits 7 to 11 of the packet header register store instruction may be used to encode the rs1 field, such as Figure 5 shown.

[0056] The function field may indicate the function or operation (eg, storage) of the instruction. In one embodiment, bits 12 to 14 of the packet header register store instruction may be used to encode the function field, such as Figure 5 As an example, bits 12 to 14 of the packet header register store instruction may be encoded as fixed values ​​001 to indicate a store function, such as Figure 5 shown.

[0057] The PHRidx field may indicate the starting position of the packet header in the packet header register. In one embodiment, bits 15 to 20 of the packet header register store instruction may be used to encode the PHRidx field, such as Figure 5 shown.

[0058] The offset field may indicate an address offset associated with the packet header. In one embodiment, bits 21 to 31 of the packet header register load instruction may be used to encode the offset field, such as Figure 5 shown.

[0059] According to some embodiments of the present disclosure, a packet header register store instruction may determine a packet header register index based on the PHRidx field, and determine a memory address based on the rs1 field and the offset field to store the bytes starting from the packet header register index in the PHR (i.e., the packet header) to the memory address x[rs1]+sign extension (offset). For example, in combination with Figure 5In the example shown, the packet header register store instruction may store the bytes in the PHR starting from PHRidx from low to high to the memory address x[rs1]+sign extension (offset).

[0060] It is understandable that the above combination Figure 5 The various details of the embodiments of the packet header register load or store instruction described above are merely exemplary for the purpose of illustration and are not intended to be limiting. Various modifications or substitutions may be made by those skilled in the art without departing from the scope of the present disclosure.

[0061] Packet header parsing instructions Figure 6 An example of encoding of packet header parsing instructions according to an embodiment of the present disclosure is illustrated. Packet Header Parsing Instructions (PHPI) can be used to parse IPv4, IPv6, Ethernet, and TCP packet headers. For an IPv4 or IPv6 packet header, the packet header parsing instructions can extract fields such as the IP address, Time to Live (TTL), and protocol. For an Ethernet packet header, a single packet header parsing instruction can retrieve the source Media Access Control (MAC) address, the destination MAC address, and the Ethernet type field. For a TCP packet header, the packet header parsing instructions can quickly extract fields such as the source port, destination port, sequence number, and acknowledgment number.

[0062] like Figure 6 As shown, the packet header parsing instruction according to an embodiment of the present disclosure may be encoded with an NP opcode field, a destination register (rd) field, a function (funct3) field, a first source register (rs1) field, a second source register (rs2) field, and a PHR index (PHRidx) field. The following Table 1 shows the Figure 6 Description of each field of the packet header parsing instruction shown.

[0063] Table 1

[0064] The NP opcode field may indicate a network processor instruction opcode. In one embodiment, bits 0 to 6 of the packet header parsing instruction may be used to encode the NP opcode field, such as Figure 6 shown.

[0065] The rd field may indicate a destination register for storing the parsed field result. In one embodiment, bits 7 to 11 of the packet header parsing instruction may be used to encode the rd field, such as Figure 6 shown.

[0066] The funct3 field can be used to distinguish the parsing instructions of different protocols. In one embodiment, bits 12 to 14 of the packet header parsing instruction can be used to encode the funct3 field, such as Figure 6 As shown. As an example, the 12th to 14th bits of the funct3 field of the packet header parsing instruction are encoded as 100, which can indicate that the IPv4 packet header is to be parsed, the 12th to 14th bits of the funct3 field of the packet header parsing instruction are encoded as 101, which can indicate that the Ethernet packet header is to be parsed, the 12th to 14th bits of the funct3 field of the packet header parsing instruction are encoded as 110, which can indicate that the IPv6 packet header is to be parsed, and the 12th to 14th bits of the funct3 field of the packet header parsing instruction are encoded as 111, which can indicate that the TCP packet header is to be parsed, as shown. Figure 6 shown.

[0067] The rs1 field may indicate a first source register for selecting the type of field to be extracted. In one embodiment, bits 15 to 19 of the packet header parsing instruction may be used to encode the rs1 field, such as Figure 6 As shown. As an example, the value of the rs1 field of the 15th to 19th bits of the packet header parsing instruction is 0, which can indicate that the extracted field is the source IP, the value of the rs1 field of the 15th to 19th bits of the packet header parsing instruction is 1, which can indicate that the extracted field is the destination IP, the value of the rs1 field of the 15th to 19th bits of the packet header parsing instruction is 2, which can indicate that the extracted field is the source port, the value of the rs1 field of the 15th to 19th bits of the packet header parsing instruction is 3, which can indicate that the extracted field is the destination port, the value of the rs1 field of the 15th to 19th bits of the packet header parsing instruction is 4, which can indicate that the extracted field is TTL, and so on.

[0068] The rs2 field may indicate a second source register for specifying a particular parsing operation. In one embodiment, bits 20 to 24 of the packet header parsing instruction may be used to encode the rs2 field, such as Figure 6 As shown. As an example, the default value of the rs2 field of the 20th to 24th bits of the packet header parsing instruction can be 0, indicating that the field is not modified. For example, the value of the rs2 field of the 20th to 24th bits of the packet header parsing instruction is 1, which can indicate that the value of the TTL field is increased by 1 to extend the life of the packet, and so on.

[0069] The PHRidx field may indicate a packet header register index, which indicates the starting position of reading the packet header in the packet header register. In one embodiment, bits 25 to 31 of the packet header parsing instruction may be used to encode the PHRidx field, such as Figure 6As shown. As an example, a value of 4 in the PHRidx field may indicate that extraction starts from the 4th byte of the PHR.

[0070] For ease of explanation only, an example scenario is used below to illustrate the acceleration effect of the packet header parsing instruction according to an embodiment of the present disclosure. The example scenario is as follows: a data packet containing an IPv4 header enters the network processor. Assuming that the IPv4 header occupies the first 20 bytes, the NP needs to extract the source IP address, destination IP address, and TTL field from the IPv4 header. The example scenario is represented below using traditional RISC-V instructions and extended PHPI instructions according to the present disclosure. First, the traditional RISC-V instructions are as follows: # Assume x5 contains the starting address of the IPv4 header lw x6, 12(x5) #Read the source IP address from the 12-byte offset of address x5 and store it in x6 lw x7, 16(x5) #Read the destination IP address from the 16-byte offset of address x5 and store it in x7 lb x8, 8(x5) #Read the TTL field from the 8-byte offset at address x5 and store it in x8 addi x9, x8, 1 #read the TTL field from x8, add 1 and store it in x9 Then, the extended PHPI instruction according to the present disclosure may be as follows: phrld PHR, x5 #Read 64 bytes from address x5 and store them in PHR phpi x6 PHR 0 #Read the source IP address from PHR and store it in x6 phpi x7 PHR 1 #Read the destination IP address from PHR and store it in x7 phpi x9 PHR 4 1 #read the TTL field from PHR, add 1 and store it in x9 As can be seen, the parsing method used by traditional RISC-V instructions requires a memory access operation for each field read and parsed. In contrast, using PHR load and PHPI instructions only requires a single memory access. This greatly reduces the processing time during packet processing.

[0071] It is understandable that the above combination Figure 6 The various details of the embodiments of the packet header parsing instructions are merely exemplary for the purpose of illustration and are not restrictive. A person skilled in the art may make various modifications or substitutions without departing from the scope of the present disclosure.

[0072] Packet header checksum instructions Checksums are commonly used in various network protocols to ensure the integrity and correctness of data during transmission. For example, the IPv4 checksum is used to check whether the information within the IP header has errors. The Internet Checksum Algorithm is used to calculate the checksum of the IPv4, TCP, and UDP headers. It divides the data into 16-bit blocks, performs a binary sum, and then takes the 1's complement of the sum to produce the checksum.

[0073] According to an embodiment of the present disclosure, a customized RISC-V instruction for checksum calculation is proposed, which will significantly improve the performance of processing network data packets by reducing the number of instructions required for checksum calculation.

[0074] Figure 7 FIG. 2 illustrates an example of encoding of packet header checksum instructions (PHCHK) according to an embodiment of the present disclosure. Figure 7 As shown, the packet header checksum instruction according to an embodiment of the present disclosure may be encoded with an NP opcode field, a destination register (rd) field, a function (funct3) field, a first source register (rs1) field, a PHR index (PHRidx) field, and a reserved (reserved) field. The following Table 2 shows the Figure 7 A description of the various fields of the packet header checksum instruction is shown.

[0075] Table 2

[0076] The NP opcode field may indicate a network processor instruction opcode. In one embodiment, bits 0 to 6 of the packet header checksum instruction may be used to encode the NP opcode field, such as Figure 6 shown.

[0077] The rd field may indicate a destination register for storing the final checksum result. In one embodiment, bits 7 to 11 of the packet header checksum instruction may be used to encode the rd field, such as Figure 6 shown.

[0078] The function field may indicate the function or operation of the instruction (e.g., a checksum function). In one embodiment, bits 12 to 14 of the packet header checksum instruction may be used to encode the function field, such as Figure 7 As shown. As an example, bits 12 to 14 of the packet header checksum instruction can be encoded as fixed values ​​010 to indicate the checksum calculation function, such as Figure 7 shown.

[0079] The rs1 field may indicate a first source register for storing the byte length of the data to be processed. In one embodiment, bits 15 to 19 of the packet header checksum instruction may be used to encode the rs1 field, such as Figure 7 shown.

[0080] The PHRidx field may indicate a packet header register index, which indicates the starting position of reading the packet header in the packet header register. In one embodiment, bits 20 to 25 of the packet header checksum instruction may be used to encode the PHRidx field, such as Figure 7 As shown. As an example, a value of 4 in the PHRidx field may indicate that extraction starts from the 4th byte of the PHR.

[0081] The reserved field may indicate a reserved field for use with any appropriate field required.

[0082] For ease of explanation only, an example scenario is used below to illustrate the acceleration effect of the packet header checksum instruction according to an embodiment of the present disclosure. The example scenario is as follows: Assume that the checksum of a 40-byte data packet (typical IPv4 header length) needs to be calculated, and the checksum calculation is performed in units of 16 bits (2 bytes). The example scenario is represented below using traditional RISC-V instructions and the extended packet header checksum instruction (PHCHK) according to the present disclosure. First, the traditional RISC-V instruction is as follows: li t0, 0#Initialize the checksum to 0 li t1, data_addr #data address li t2, 20#Number of data blocks (40 bytes, 20 16-bit blocks) loop: lhu t3, 0(t1) #load the next 16-bit block from memory add t0, t0, t3 #accumulate checksum sltiu t4, t0, t3#check carry add t0, t0, t4#If there is a carry, add it back addi t1, t1, 2 #point to the next 16-bit block addi t2, t2, -1#decrease block count bnez t2, loop#If there are more blocks, continue not t0, t0#Finally, take the 1's complement of the checksum The above traditional RISC-V instruction operation requires 20 loop iterations, each iteration involving instructions for loading, accumulation, carry check, carry processing, pointer update, and counter update.

[0083] Then, the extended packet header checksum instruction (PHCHK) according to the present disclosure is as follows: phrld PHR, t1 # load 64 bytes from data address and store it in PHR li t2, 40 #Length from data byte to checksum phchk t0, t2, PHR #Read 0-39 bytes from PHR and perform checksum #Calculate and write the result into t0.

[0084] It can be seen that by using PHR loading and extended PHCHK instructions, combined with related hardware, only 3 instructions and one memory access are needed to complete the calculation. Compared with traditional RISC-V instructions (20 memory accesses and about 160 instructions), the number of instructions is significantly reduced, resulting in about 50 times performance improvement or acceleration in terms of the number of instructions.

[0085] It is understandable that the above combination Figure 7 The various details of the embodiments of the packet header checksum instruction described above are merely exemplary for the purpose of illustration and are not intended to be limiting. Various modifications or substitutions may be made by those skilled in the art without departing from the scope of the present disclosure.

[0086] According to the embodiments of the present disclosure, the packet header register load or store instructions, the packet header parsing instructions, and the packet header checksum instructions can accelerate the network processor designed based on the RISC-V ISA, filling the gap of RISC-V in network packet processing.

[0087] Figure 8 The flowchart of a processing method 800 according to some embodiments of the present disclosure is illustrated. In some embodiments, the method 800 may be executed at a processing device. The method 800 may include steps 810 and 820.

[0088] At step 810, a received packet processing instruction may be decoded, wherein the packet processing instruction is used to process a packet header.

[0089] In some embodiments, the packet processing instructions may include one or more of: a packet header register load instruction, a packet header register store instruction, a packet header parsing instruction, and a packet header checksum instruction.

[0090] At step 820, the decoded packet processing instructions may be executed to process the packet header.

[0091] In some embodiments, the packet header register load instruction may include: a source register field for indicating a source register, wherein the source register stores memory address information related to the packet header; and an offset field for indicating an address offset related to the packet header. In some embodiments, executing the decoded packet processing instruction to process the packet header may include: executing the decoded packet header register load instruction to read the packet header from a memory address determined based on the memory address information and the address offset, and writing the read packet header into the packet header register.

[0092] In some embodiments, the packet header register store instruction may include: a packet header register index field for indicating a starting position of reading a packet header in a packet header register; a source register field for indicating a source register, wherein the source register stores memory address information related to the packet header; and an offset field for indicating an address offset related to the packet header. In some embodiments, executing the decoded packet processing instruction to process the packet header may include: executing the decoded packet header register store instruction to store bytes in the packet header register starting from the packet header register index to a memory address determined based on the memory address information and the address offset.

[0093] In some embodiments, the packet header parsing instruction may include: a function field for distinguishing parsing instructions of different network protocols; a first source register field for indicating a first source register, wherein the first source register is used to select the type of field to be extracted; a second source register field for indicating a second source register, wherein the second source register is used to specify a specific parsing operation; a destination register field for indicating a destination register, wherein the destination register is used to store the parsed field result; and a packet header register index field for indicating the starting position of reading the packet header in the packet header register. In some embodiments, executing the decoded packet processing instruction to process the packet header may include: executing the decoded packet header parsing instruction to read the field specified by the first source register field from the packet header register.

[0094] In some embodiments, the packet header checksum instruction may include: a source register field for indicating a source register, wherein the source register stores a byte length of data to be processed; a destination register field for indicating a destination register, wherein the destination register is used to store a final checksum result; and a packet header register index field for indicating a starting position for reading a packet header in the packet header register. In some embodiments, executing the decoded packet processing instruction to process the packet header may include: executing the decoded packet header checksum instruction to read bytes of the byte length specified by the source register field from the packet header register, calculating a checksum for the bytes read, and storing the calculated checksum result in the destination register.

[0095] It is understood that the specific details of the method 800 can be referred to in conjunction with the above Figures 1 to 7 The specific contents and related contents are not repeated here. In addition, it is understood that the method 800 may include more, less or different steps in some other embodiments, which is not limited here.

[0096] The embodiments or examples disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementation approaches. The embodiments or examples may be implemented as a computer program or program code, executed on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0097] One or more aspects of at least one embodiment or example may be implemented by representative instructions stored on a machine-readable medium, which represent various logics within a processor, and which, when read by a machine, cause the machine to fabricate logic for performing the techniques described herein. These representations are referred to as "intellectual property (IP) cores" and may be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into a fabrication machine that fabricates the logic or processor.

[0098] These machine-readable storage media may include, but are not limited to, non-transitory tangible arrangements of articles made or formed by a machine or device, including storage media such as: hard disks, any other type of disk (including floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks), semiconductor devices (e.g., read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase change memory (PCM)), magnetic or optical cards, or any other type of medium suitable for storing electronic instructions.

[0099] The following paragraphs describe examples of various embodiments.

[0100] Example 1 includes a packet processing device, including: a decoding circuit for decoding a received packet processing instruction, wherein the packet processing instruction is used to process a packet header; and a packet header register for storing the packet header.

[0101] Example 2 includes the apparatus of Example 1, wherein the length of the packet header register is 64 bytes.

[0102] Example 3 includes the apparatus of Example 2, wherein the packet processing instructions include one or more of: a packet header register load instruction, a packet header register store instruction, a packet header parsing instruction, and a packet header checksum instruction.

[0103] Example 4 includes the apparatus of Example 3, wherein the packet header register load instruction comprises: a source register field for indicating a source register, wherein the source register stores memory address information related to the packet header; and an offset field for indicating an address offset related to the packet header.

[0104] Example 5 includes the device described in Example 4, further comprising: an execution circuit for executing a decoded packet header register load instruction to read the packet header from a memory address determined based on the memory address information and the address offset, and write the read packet header into the packet header register.

[0105] Example 6 includes the device described in Example 4, further comprising: an execution circuit for executing a decoded packet header register load instruction to read 64 consecutive bytes from a memory address determined based on the memory address information and the address offset, and write the read 64 consecutive bytes into the packet header register.

[0106] Example 7 includes the apparatus described in Example 3, wherein the packet header register storage instruction comprises: a packet header register index field for indicating a starting position for reading the packet header in the packet header register; a source register field for indicating a source register, wherein the source register stores memory address information related to the packet header; and an offset field for indicating an address offset related to the packet header.

[0107] Example 8 includes the apparatus described in Example 7, further comprising: an execution circuit for executing a decoded packet header register storage instruction to store bytes in the packet header register starting from the packet header register index into a memory address determined based on the memory address information and the address offset.

[0108] Example 9 includes the apparatus described in Example 3, wherein the packet header parsing instruction comprises: a function field for distinguishing parsing instructions of different network protocols; a first source register field for indicating a first source register, wherein the first source register is used to select the type of packet header field to be extracted; a second source register field for indicating a second source register, wherein the second source register is used to specify a specific parsing operation; a destination register field for indicating a destination register, wherein the destination register is used to store the parsed field result; and a packet header register index field for indicating the starting position of reading the packet header in the packet header register.

[0109] Example 10 includes the apparatus of Example 9, wherein the different network protocols include one or more of: IPv4, IPv6, Ethernet, and Transmission Control Protocol.

[0110] Example 11 includes the apparatus of Example 10, wherein, for IPv4 or IPv6 protocol, the type of packet header field to be extracted includes one or more of the following items: an Internet Protocol address field, a Time to Live TTL field, and a protocol field.

[0111] Example 12 includes the apparatus of Example 10, wherein, for the Ethernet protocol, the type of packet header field to be extracted includes one or more of the following items: a source media access control address field, a destination media access control address field, and an Ethernet type field.

[0112] Example 13 includes the apparatus of Example 10, wherein, for the Transmission Control Protocol, the type of packet header field to be extracted includes one or more of the following items: a source port field, a destination port field, a sequence number field, and an acknowledgment number field.

[0113] Example 14 includes the apparatus of Example 9, wherein the specific parsing operation is used to limit whether to modify the packet header field to be extracted.

[0114] Example 15 includes the apparatus of Example 9, further comprising: execution circuitry for executing the decoded packet header parsing instruction to read the field specified by the first source register field from the packet header register.

[0115] Example 16 includes the apparatus of Example 3, wherein the packet header checksum instruction comprises: a source register field for indicating a source register, wherein the source register stores a byte length of data to be processed; a destination register field for indicating a destination register, wherein the destination register is used to store a final checksum result; and a packet header register index field for indicating a starting position for reading the packet header in the packet header register.

[0116] Example 17 includes the apparatus of Example 16, further comprising: an execution circuit for executing a decoded packet header checksum instruction to read bytes of the byte length specified by the source register field from the packet header register, calculate a checksum for the read bytes, and store the calculated checksum result in the destination register.

[0117] Example 18 includes a packet processing method, comprising: decoding a received packet processing instruction, wherein the packet processing instruction is used to process a packet header; executing the decoded packet processing instruction to process the packet header.

[0118] Example 19 includes the method of Example 18, wherein the packet processing instructions include one or more of: a packet header register load instruction, a packet header register store instruction, a packet header parsing instruction, and a packet header checksum instruction.

[0119] Example 20 includes the method described in Example 19, wherein the packet header register load instruction includes: a source register field for indicating a source register, wherein the source register stores memory address information related to the packet header; and an offset field for indicating an address offset related to the packet header.

[0120] Example 21 includes the method described in Example 20, wherein executing a decoded packet processing instruction to process the packet header includes: executing a decoded packet header register loading instruction to read the packet header from a memory address determined based on the memory address information and the address offset, and writing the read packet header into a packet header register.

[0121] Example 22 includes the method described in Example 19, wherein the packet header register storage instruction includes: a packet header register index field, used to indicate the starting position of reading the packet header in the packet header register; a source register field, used to indicate a source register, wherein the source register stores memory address information related to the packet header; and an offset field, used to indicate an address offset related to the packet header.

[0122] Example 23 includes the method described in Example 22, wherein executing a decoded packet processing instruction to process the packet header includes: executing a decoded packet header register storage instruction to store bytes in the packet header register starting from the packet header register index into a memory address determined based on the memory address information and the address offset.

[0123] Example 24 includes the method described in Example 19, wherein the packet header parsing instruction includes: a function field for distinguishing parsing instructions of different network protocols; a first source register field for indicating a first source register, wherein the first source register is used to select the type of packet header field to be extracted; a second source register field for indicating a second source register, wherein the second source register is used to specify a specific parsing operation; a destination register field for indicating a destination register, wherein the destination register is used to store the parsed field result; and a packet header register index field for indicating the starting position of reading the packet in the packet header register.

[0124] Example 25 includes the method of Example 24, wherein executing the decoded packet processing instruction to process the packet header comprises: executing the decoded packet header parsing instruction to read the field specified by the first source register field from the packet header register.

[0125] Example 26 includes the method described in Example 19, wherein the packet header checksum instruction includes: a source register field for indicating a source register, wherein the source register stores the byte length of data to be processed; a destination register field for indicating a destination register, wherein the destination register is used to store a final checksum result; and a packet header register index field for indicating the starting position of reading the packet header in the packet header register.

[0126] Example 27 includes the method of Example 26, wherein executing the decoded packet processing instruction to process the packet header includes: executing the decoded packet header checksum instruction to read bytes of the byte length specified by the source register field from the packet header register, calculating a checksum for the read bytes, and storing the calculated checksum result in the destination register.

[0127] Example 28 includes a computer-readable storage medium having computer-executable instructions stored thereon, wherein the computer-executable instructions, when executed by a processing circuit, cause the processing circuit to perform a method as described in any of Examples 18-27.

[0128] Although certain embodiments are illustrated and described herein for descriptive purposes, various alternative and / or equivalent embodiments or implementations planned to achieve the same purpose may replace the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptation or variation of the embodiments discussed herein. Therefore, it is readily understood that the embodiments described herein are limited only by the appended claims and their equivalents.

Claims

1. A packet processing device, comprising: A decoding circuit, configured to decode a received packet processing instruction, wherein the packet processing instruction is configured to process a packet header; and The packet header register is used to store the packet header.

2. The device according to claim 1, wherein: The length of the packet header register is 64 bytes.

3. The device as claimed in claim 2, wherein: The packet processing instructions include one or more of the following: a packet header register load instruction, a packet header register store instruction, a packet header parsing instruction, and a packet header checksum instruction.

4. The device as claimed in claim 3, wherein: The packet header register load instruction comprises: a source register field, used to indicate a source register, wherein the source register stores memory address information related to the packet header; and The offset field is used to indicate the address offset related to the packet header.

5. The apparatus of claim 4, further comprising: An execution circuit is configured to execute the decoded packet header register load instruction to read the packet header from a memory address determined based on the memory address information and the address offset, and write the read packet header into the packet header register.

6. The apparatus of claim 4, further comprising: An execution circuit is used to execute the decoded packet header register load instruction to read 64 consecutive bytes from a memory address determined based on the memory address information and the address offset, and write the read 64 consecutive bytes into the packet header register.

7. The device of claim 3, wherein: The packet header register storage instruction includes: A packet header register index field, used to indicate the starting position of reading the packet header in the packet header register; a source register field, used to indicate a source register, wherein the source register stores memory address information related to the packet header; and The offset field is used to indicate the address offset related to the packet header.

8. The apparatus of claim 7, further comprising: An execution circuit is configured to execute the decoded packet header register store instruction to store bytes in the packet header register starting from the packet header register index into a memory address determined based on the memory address information and the address offset.

9. The device of claim 3, wherein: The packet header parsing instruction includes: Function field, used to distinguish parsing instructions of different network protocols; A first source register field, used to indicate a first source register, wherein the first source register is used to select a type of packet header field to be extracted; A second source register field, used to indicate a second source register, wherein the second source register is used to specify a specific parsing operation; a destination register field, used to indicate a destination register, wherein the destination register is used to store the parsed field result; and The packet header register index field is used to indicate the starting position of reading the packet header in the packet header register.

10. The device of claim 9, wherein: The different network protocols include one or more of the following: IPv4, IPv6, Ethernet, and Transmission Control Protocol.

11. The device of claim 10, wherein: For IPv4 or IPv6 protocol, the type of the packet header field to be extracted includes one or more of the following items: an Internet Protocol address field, a Time To Live TTL field, and a protocol field.

12. The device of claim 10, wherein: For the Ethernet protocol, the type of the packet header field to be extracted includes one or more of the following items: a source media access control address field, a destination media access control address field, and an Ethernet type field.

13. The device of claim 10, wherein: For the transmission control protocol, the type of the packet header field to be extracted includes one or more of the following items: a source port field, a destination port field, a sequence number field, and an acknowledgment number field.

14. The device of claim 9, wherein: The specific parsing operation is used to determine whether to modify the packet header field to be extracted.

15. The apparatus of claim 9, further comprising: The execution circuit is configured to execute the decoded packet header parsing instruction to read the field specified by the first source register field from the packet header register.

16. The device of claim 3, wherein: The packet header checksum instruction includes: A source register field, used to indicate a source register, wherein the source register stores the byte length of data to be processed; a destination register field, used to indicate a destination register, wherein the destination register is used to store a final checksum result; and The packet header register index field is used to indicate the starting position of reading the packet header in the packet header register.

17. The apparatus of claim 16, further comprising: An execution circuit is configured to execute the decoded packet header checksum instruction to read bytes of the byte length specified by the source register field from the packet header register, calculate a checksum for the bytes read, and store the calculated checksum result in the destination register.

18. A group processing method, comprising: Decoding a received packet processing instruction, wherein the packet processing instruction is used to process a packet header; The decoded packet processing instructions are executed to process the packet header.

19. The method of claim 18, wherein: The packet processing instructions include one or more of the following: a packet header register load instruction, a packet header register store instruction, a packet header parsing instruction, and a packet header checksum instruction.

20. The method of claim 19, wherein: The packet header register load instruction comprises: a source register field, used to indicate a source register, wherein the source register stores memory address information related to the packet header; and The offset field is used to indicate the address offset related to the packet header.

21. The method of claim 20, wherein: Executing the decoded packet processing instruction to process the packet header includes: The decoded packet header register load instruction is executed to read the packet header from the memory address determined based on the memory address information and the address offset, and to write the read packet header into the packet header register.

22. The method of claim 19, wherein: The packet header register storage instruction includes: A packet header register index field, used to indicate the starting position of reading the packet header in the packet header register; a source register field, used to indicate a source register, wherein the source register stores memory address information related to the packet header; and The offset field is used to indicate the address offset related to the packet header.

23. The method of claim 22, wherein: Executing the decoded packet processing instruction to process the packet header includes: The decoded packet header register store instruction is executed to store bytes in the packet header register starting from the packet header register index into a memory address determined based on the memory address information and the address offset.

24. The method of claim 19, wherein: The packet header parsing instruction includes: Function field, used to distinguish parsing instructions of different network protocols; A first source register field, used to indicate a first source register, wherein the first source register is used to select a type of packet header field to be extracted; A second source register field, used to indicate a second source register, wherein the second source register is used to specify a specific parsing operation; a destination register field, used to indicate a destination register, wherein the destination register is used to store the parsed field result; and The packet header register index field is used to indicate the starting position of the packet in the packet header register for reading.

25. The method of claim 24, wherein: Executing the decoded packet processing instruction to process the packet header includes: The decoded packet header parsing instruction is executed to read the field specified by the first source register field from the packet header register.

26. The method of claim 19, wherein: The packet header checksum instruction includes: A source register field, used to indicate a source register, wherein the source register stores the byte length of data to be processed; a destination register field, used to indicate a destination register, wherein the destination register is used to store a final checksum result; and The packet header register index field is used to indicate the starting position of reading the packet header in the packet header register.

27. The method of claim 26, wherein: Executing the decoded packet processing instruction to process the packet header includes: The decoded packet header checksum instruction is executed to read bytes of the byte length specified by the source register field from the packet header register, calculate a checksum for the bytes read, and store the calculated checksum result in the destination register.

28. A computer-readable storage medium having computer-executable instructions stored thereon, wherein the computer-executable instructions, when executed by a processing circuit, cause the processing circuit to perform the method of any one of claims 18-27.

Images