Message address searching method and device based on flow identification, equipment and storage medium

Abstract

The invention discloses a message address searching method and device based on flow identification, equipment and a storage medium, relates to the technical field of network communication, and discloses a message address searching method based on flow identification, which comprises the following steps: when an establishment request of a target connection is detected, allocating a context slot position and security verification information for the target connection, obtaining index information and verification information, and generating initial stream identification information according to the index information and the verification information; sending the initial flow identification information to the sending end through the target connection, so that the sending end generates a target data message according to the initial flow identification information and feeds back the target data message; analyzing the target data message to obtain target flow identification information, and verifying the target flow identification information to obtain a target verification result; and determining a target search strategy according to the target verification result, and determining a context physical address according to the target search strategy so as to complete message address search based on the flow identifier. And the deterministic and low-delay message address searching of the data plane is realized.

Description

Method, apparatus, device and storage medium for message address lookup based on flow identifier Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a method, apparatus, device and storage medium for message address lookup based on flow identifiers. Background Technology

[0002] In modern high-performance computing and artificial intelligence clusters, Remote Direct Data Access over Converged Ethernet version 2 (RoCEv2) has become the mainstream network interconnection technology. It achieves low-latency data transmission through Remote Direct Memory Access (RDMA) technology, making it particularly suitable for massively parallel computing environments. However, RoCEv2 implementations typically rely on the network interface card (NIC) to identify and locate the connection context to which a packet belongs by using destination queue pair sequence numbers. Since the RDMA connection establishment process requires the operating system to randomly assign queue pair sequence numbers, and there is no linear relationship between these queue pair sequence numbers and the physical addresses within the NIC, context location becomes complex.

[0003] Traditional solutions primarily rely on hash lookups or multi-level page table translation mechanisms to locate context. These solutions depend on hash algorithms to map logical queue pair sequence numbers to physical memory addresses within the network interface card (NIC). However, this approach has significant drawbacks when dealing with ultra-large-scale clusters. As the cluster size increases, the NIC's context cache capacity becomes limited. When a cache miss occurs, the hardware needs to initiate expensive memory accesses, leading to a significant increase in processing latency and severely impacting system performance.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a method, apparatus, device, and storage medium for message address lookup based on flow identifiers, aiming to solve the technical problem that the existing RoCEv2 receiver relies on a complex lookup mechanism for locating the connection context, resulting in unpredictable message processing latency and significant long-tail latency in high-concurrency scenarios.

[0006] To achieve the above objectives, this application proposes a packet address lookup method based on flow identifiers. The method includes: when a target connection establishment request is detected, allocating a context slot and security verification information to the target connection to obtain index information and verification information, and generating initial flow identifier information based on the index information and the verification information; sending the initial flow identifier information to a sending end through the target connection, so that the sending end generates a target data packet based on the initial flow identifier information and provides feedback; parsing the target data packet to obtain target flow identifier information, and verifying the target flow identifier information to obtain a target verification result; determining a target lookup strategy based on the target verification result, and determining the context physical address based on the target lookup strategy to complete the packet address lookup based on flow identifiers.

[0007] In one embodiment, the step of allocating context slots and security verification information to the target connection when a target connection establishment request is detected, obtaining index information and verification information, and generating initial flow identification information based on the index information and the verification information includes: determining the service type of the target connection when a target connection establishment request is detected; allocating context slots and security verification information to the target connection when the service type is a first priority service, obtaining index information and security verification information; and combining and encoding the index information and the security verification information to obtain initial flow identification information.

[0008] In one embodiment, the step of allocating context slots and security verification information to the target connection and obtaining index information and verification information when the service type is a first priority service includes: determining context slots in the physical memory region when the service type is a first priority service; determining the storage location of the target connection in the context slots and generating index information; and generating a security verification code according to a random generation strategy to obtain security verification information.

[0009] In one embodiment, the step of determining a target lookup strategy based on the target verification result and determining a context physical address based on the target lookup strategy to complete the packet address lookup based on the flow identifier includes: when the target verification result is a security verification pass, determining the target lookup strategy as a flow identifier lookup strategy; determining the fast pool base address register value, the context entry size, and the offset index in the target flow identifier information based on the flow identifier lookup strategy; and performing address calculation based on the fast pool base address register value, the context entry size, and the offset index to obtain the context physical address, thereby completing the packet address lookup based on the flow identifier.

[0010] In one embodiment, the step of parsing the target data packet to obtain target flow identification information includes: parsing the target data packet to obtain an offset index and security verification information; and generating target flow identification information based on the offset index and the security verification information.

[0011] In one embodiment, the step of verifying the target flow identifier information to obtain a target verification result includes: obtaining a local security configuration; performing security verification on the target flow identifier information to obtain security verification information of the target flow identifier information; determining whether the security verification information of the target flow identifier information is the same as the local security configuration; and determining that the target verification result is a security verification passed when the security verification information of the target flow identifier information is the same as the local security configuration.

[0012] In one embodiment, before the step of determining the target lookup strategy based on the target verification result and determining the context physical address based on the target lookup strategy to complete the packet address lookup based on the flow identifier, the method further includes: when it is detected that the number of current cluster connections exceeds the preset flow identifier representation range, sorting the target connections according to the connection activity to obtain the cluster connection ranking; mapping the target connections whose cluster connection ranking is greater than or equal to a preset sequence number threshold to the context slot; and storing the target connections whose cluster connection ranking is less than the preset sequence number threshold to a preset hash table structure for hardware resource allocation.

[0013] Furthermore, to achieve the above objectives, this application also proposes a packet address lookup device based on flow identifiers. The device includes: an identifier generation module, configured to allocate context slots and security verification information to the target connection when a target connection establishment request is detected, obtain index information and verification information, and generate initial flow identifier information based on the index information and the verification information; a packet receiving module, configured to send the initial flow identifier information to a sending end through the target connection, so that the sending end generates a target data packet based on the initial flow identifier information and provides feedback; an identifier verification module, configured to parse the target data packet to obtain target flow identifier information, and verify the target flow identifier information to obtain a target verification result; and an address lookup module, configured to determine a target lookup strategy based on the target verification result, and determine the context physical address based on the target lookup strategy, thereby completing the packet address lookup based on flow identifiers.

[0014] Furthermore, to achieve the above objectives, this application also proposes a packet address lookup device based on flow identifiers, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the packet address lookup method based on flow identifiers as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the packet address lookup method based on flow identifier as described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the packet address lookup method based on flow identifier as described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: By employing a method that allocates context slots and security verification information to the target connection when a target connection establishment request is detected, obtains corresponding index information and verification information, generates initial flow identifier information accordingly, sends the initial flow identifier information to the sender through the target connection so that the sender generates and returns a target data packet based on this information, parses the target data packet to obtain the target flow identifier information, verifies this information to obtain the target verification result, and then determines the target lookup strategy based on the target verification result and determines the context physical address according to the strategy to complete the packet address lookup, this method solves the problem of reliance on queues in existing technologies. For sequence numbers, the connection context is located through hash lookup or multi-level page table conversion mechanism. In ultra-large-scale cluster scenarios, cache misses are prone to occur, resulting in severe long-tail latency. Hash collisions further reduce processing efficiency, and the packet parsing path is long and consumes a lot of logical resources, making it difficult to meet the line-speed small packet processing requirements of ultra-high-speed networks and failing to guarantee the deterministic latency required for high-performance computing. Compared with existing technologies, this method bypasses the traditional queue-based hash lookup and multi-level page table conversion process for sequence numbers, achieving fast location of the context physical address with constant time complexity. It completely eliminates the performance jitter caused by long-tail latency and hash collisions, and achieves deterministic low-latency forwarding of the data plane. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 is a flowchart illustrating the first embodiment of the packet address lookup method based on flow identifiers of this application; Figure 2 is a schematic diagram illustrating the system architecture and negotiation handshake process of the first embodiment of the packet address lookup method based on flow identifiers of this application; Figure 3 is a schematic diagram illustrating the packet structure and field definition, i.e., tag placement and protocol compatibility, of the first embodiment of the packet address lookup method based on flow identifiers of this application; Figure 4 is a schematic diagram illustrating the direct index implementation of the logical-to-physical mapping, i.e., the NPC concept, of the first embodiment of the packet address lookup method based on flow identifiers of this application; Figure 5 is a comparative schematic diagram illustrating the traditional RoCEv2 hash lookup and the proposed packet address lookup scheme based on flow identifiers of this application; Figure 6 is a flowchart illustrating the second embodiment of the packet address lookup method based on flow identifiers of this application; Figure 7 is a schematic diagram illustrating the module structure of the packet address lookup device based on flow identifiers of this application; Figure 8 is a schematic diagram illustrating the device structure of the hardware operating environment involved in the packet address lookup method based on flow identifiers of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution of this application embodiment is as follows: When a target connection establishment request is detected, a context slot and security verification information are allocated to the target connection to obtain index information and verification information, and initial flow identification information is generated according to the index information and the verification information; the initial flow identification information is sent to the sending end through the target connection so that the sending end generates a target data packet according to the initial flow identification information and sends it back; the target data packet is parsed to obtain the target flow identification information, and the target flow identification information is verified to obtain the target verification result; a target lookup strategy is determined according to the target verification result, and the context physical address is determined according to the target lookup strategy to complete the packet address lookup based on the flow identifier.

[0025] In this embodiment, for ease of description, the following description will focus on identifying a packet address lookup device based on flow identifiers.

[0026] Because existing RoCEv2 receivers rely on complex lookup mechanisms for locating connection contexts, resulting in unpredictable packet processing delays and significant long-tail latency in high-concurrency scenarios, this application provides a solution. This solution allocates context slots and security verification information to the target connection upon detecting a connection establishment request, obtaining corresponding index and verification information, and generating initial flow identifier information accordingly. This initial flow identifier information is then sent to the sender via the target connection, enabling the sender to generate and respond with target data packets. After parsing the target data packets to obtain the target flow identifier information, this information is verified to obtain the target verification result. Finally, based on the target verification result, a target lookup strategy is determined, and the context physical address is determined according to this strategy. The proposed technique for packet address lookup addresses the shortcomings of existing technologies that rely on queue-based sequence number lookups and hash lookups or multi-level page table conversion mechanisms to locate the connection context. These methods often result in cache misses and severe long-tail latency in ultra-large-scale cluster scenarios, further exacerbated by hash collisions that reduce processing efficiency. Moreover, the long packet parsing paths and high logical resource consumption make it difficult to meet the line-rate small packet processing requirements of ultra-high-speed networks and to guarantee the deterministic latency required for high-performance computing. Compared to existing technologies, this approach bypasses the traditional queue-based sequence number hash lookup and multi-level page table conversion process, achieving rapid location of the context's physical address with constant time complexity. This completely eliminates the performance jitter caused by long-tail latency and hash collisions, enabling deterministic low-latency forwarding of the data plane.

[0027] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, a packet address lookup device based on flow identifiers, etc. The following description uses a packet address lookup device based on flow identifiers as an example to illustrate this embodiment and the subsequent embodiments.

[0028] Based on this, this application provides a packet address lookup method based on flow identifiers. Referring to Figure 1, Figure 1 is a flowchart of the first embodiment of the packet address lookup method based on flow identifiers of this application.

[0029] In this embodiment, the packet address lookup method based on flow identifier includes steps S10 to S40: Step S10, when a target connection establishment request is detected, a context slot and security verification information are allocated to the target connection to obtain index information and verification information, and initial flow identifier information is generated based on the index information and the verification information; it should be noted that the target connection establishment request is a request signal initiated by the upper-layer application to establish a remote direct memory access connection. Remote direct memory access (RDMA) is a technology that bypasses the operating system kernel to achieve direct memory access between nodes. This request will trigger the receiving end to identify the connection type and is the initial trigger signal to start subsequent addressing-related operations. This request is only initiated for business scenarios that require the establishment of such high-speed connections, and the receiving end will first determine whether it belongs to a latency-sensitive high-priority service.

[0030] Additionally, context slots are pre-allocated, contiguous, fixed-size storage locations within the receiver's fast context pool of physical memory. Each slot corresponds to a unique physical offset and is specifically used to store the context state information of remote direct memory access connections. These slots provide dedicated physical storage for the connection context and are only allocated to identified, high-priority service connections that meet the requirements.

[0031] Additionally, security verification information is information randomly generated by the receiving end for the target connection, used for authentication and legitimacy verification. It can also be called a checksum and is mainly used to prevent malicious attacks and unauthorized access by index out-of-bounds.

[0032] Additionally, the index information is the physical offset index obtained by the receiving end after allocating a context slot for the target connection. This index corresponds one-to-one with the slots in the fast context pool and has the characteristic of uniqueness.

[0033] Furthermore, the initial flow identifier information is a unified identifier generated by the receiving end after encoding and combining the index information and security verification information. It can also be called a flow tag and can carry both physical addressing and security verification information.

[0034] Understandably, the process involves first detecting whether a request to establish a target connection has been received, then identifying whether the connection is a latency-sensitive high-priority service, allocating free context slots in the fast context pool for connections that meet the requirements, randomly generating security verification information, extracting index information from the allocation results, and combining the index information and security verification information in a fixed format to generate initial flow identification information.

[0035] Step S20: The initial flow identification information is sent to the sending end through the target connection, so that the sending end generates a target data packet based on the initial flow identification information and sends it back. It should be noted that the sending end is the node that initiates the target connection establishment request and is also the sender of subsequent data packets. It consists of two core parts: a network interface card (NIC) and a driver program, enabling the storage of flow identification information and the encapsulation and transmission of data packets. This node can completely receive and persistently store the initial flow identification information sent by the receiving end, and the NIC has the hardware processing capability to accurately embed this identifier into specified fields of the packet.

[0036] Additionally, the target data packet is a Converged Ethernet Remote Direct Memory Access Version 2 (RDMA over Converged Ethernet version 2) data packet encapsulated by the sender after embedding the stored initial flow identifier information into a programmable field in the packet header. RDMA over Converged Ethernet version 2 (RoCEv2) is a remote direct memory access protocol based on Ethernet. This packet breaks with traditional designs by carrying the flow identifier information required for physical addressing.

[0037] Understandably, the generated initial flow identification information is sent to the sending end via a remote direct memory access connection establishment response message. After receiving the message, the sending end driver stores the identifier in the local connection context. When the sending end network card encapsulates the data packet, it reads the identifier and embeds it into the specified programmable field in the packet header. After generating the target data packet, it sends the result back to the receiving end.

[0038] It should be understood that during the message encapsulation and transmission phases, when the sending network interface card schedules and sends data packets, the hardware pipeline encapsulates RoCEv2 messages based on information in the connection context.

[0039] Furthermore, when the sending network card schedules a data packet to be sent, it accurately reads the pre-stored flow tag information from the connection context maintained locally for the target connection.

[0040] The flow tag is a unique identifier generated by the receiving end for the target connection during the connection establishment phase. It carries an offset index pointing to the physical slot and a checksum for security verification. It is the core identifier for enabling fast addressing and is transmitted from the receiving end to the sending end via the remote direct memory access connection establishment response message. In this embodiment, this identifier is stored in association with relevant information of the target connection and is a key basis for the sending end to encapsulate messages.

[0041] It should be noted that the flow tag is a unique identifier generated by the receiving end for the target connection during the connection establishment phase. It carries an offset index pointing to the physical slot and a checksum for security verification, serving as the core identifier for fast addressing. This identifier is transmitted from the receiving end to the sending end via the remote direct memory access connection establishment response message. In this embodiment, this identifier is stored in association with relevant information about the target connection and is a crucial basis for the sending end to encapsulate messages.

[0042] Additionally, the connection context is a collection of all configuration and associated information related to the target connection that is maintained locally by the sending end. It includes the destination Internet Protocol address, destination queue pair sequence number, and flow label, etc. It is stored and managed by the sending end's driver and is a dedicated data source for reading key information when the network card encapsulates packets.

[0043] Understandably, after obtaining the flow label information, the sending network card fills the identifier into the programmable field selected in the RoCEv2 message header.

[0044] It should be noted that programmable fields are redundant fields in the RoCEv2 message header that can be reused and redefined, and can carry additional addressing identification information without modifying the standard protocol.

[0045] In this embodiment, the 20-bit Stream Label field from the Internet Protocol version 6 (IP6) header is preferably used, but the lower 12 bits of the source port field from the User Datagram Protocol (UDP) header can also be reused. Reusing such fields will not compromise protocol compatibility and can adapt to existing network architectures.

[0046] Understandably, the sending network card completes the full encapsulation of the RoCEv2 data packet through hardware pipeline and connection context information, and then sends the encapsulated packet to the receiving end.

[0047] It should be understood that the hardware pipeline is a dedicated packet processing hardware logic built into the sending network card. It can complete various encapsulation operations of RoCEv2 packets at hardware-level processing speed. Its processing efficiency is much higher than that of software encapsulation, and it can significantly reduce the clock cycles required for single packet encapsulation.

[0048] Referring to Figure 2, Figure 2 is a schematic diagram of the system architecture and negotiation handshake process of the first embodiment of the message address lookup method based on flow identifier of this application.

[0049] As shown in Figure 2, the system is divided into two parts: the left side represents the client (sender) node, and the right side represents the server (receiver) node. Dashed arrows indicate control plane handshakes, while thick solid arrows represent data plane traffic. The client section on the left shows a client node containing a processor and network interface card (NIC), as well as a storage module with the client storage tag 0x30005, used for subsequent data packet encapsulation. The server section on the right shows the internal structure of the server node, including drivers or software modules, a fast context pool (physical memory), and the receiver NIC. The fast context pool is pre-divided into multiple consecutive context slots to store the context state information corresponding to each RDMA connection. Slot 5 is specifically marked in the figure. The process consists of four steps. Step 1 is the connection request, initiated by the client to the server, which is a control plane handshake, indicated by a dashed arrow, used to trigger the RDMA connection negotiation process. Step 2 involves allocating a context slot (slot 5) and generating a checksum. This step is performed by the server-side driver or software module upon receiving a connection request. The driver allocates an empty physical context slot (slot 5 in this example) for the target connection from the fast context pool and randomly generates a checksum for validity verification. The driver then writes or binds the context data of the connection to the allocated physical slot, thereby establishing a deterministic mapping between the logical connection and the physical slot at the system level. Step 3 is the connection response, which returns a flow tag of 0x30005 from the server to the client. This is a control plane handshake, indicated by a dashed arrow. The negotiated flow tag is carried in the private data or reserved field of the response message. This flow tag encodes the index information pointing to the allocated slot, i.e., index 5, and the security check code. The calculation method is to left-shift the check code by 16 bits and then perform an OR operation with the index. In this example, the tag value is 0x30005, which means that the high 4 bits are the check code 3 and the low 16 bits are the index 5. After receiving the response, the client driver records the flow tag and stores it in the local connection context for subsequent data transmission. Step 4 is RoCEv2 data transmission, i.e., the packet header carries a tag. In the data transmission phase after the connection is established, the client network card hardware automatically reads the pre-stored tag information in the context when encapsulating subsequent RoCEv2 data packets and fills it into the predetermined programmable field in the packet header. In this example, the packet header tag is equal to 0x30005. This data plane traffic is represented by a thick solid arrow. When the packet arrives at the receiving end, the receiving network card does not need to perform a traditional hash lookup, but directly accesses slot 5 and uses the index from the tag to directly locate the physical address through the arithmetic operation of the base address plus the offset. This achieves one-step indexing and direct hit context acquisition, which significantly reduces processing latency.

[0050] Referring to Figure 3, Figure 3 is a schematic diagram of the message structure and field definition, i.e., tag placement and protocol compatibility, of the first embodiment of the message address lookup method based on flow identifier of this application.

[0051] As shown in Figure 3, the overall structure employs a layered approach to demonstrate the RoCEv2 packet encapsulation format and the reuse method of the IPv6 flow label field. The top layer displays the complete structure of the RoCEv2 packet, from left to right: Ethernet header, IP header (Internet Protocol Version 6, IPv6), User Datagram Protocol (UDP) header, InfiniBand Base Transport Header (IB BTH), and payload. These five parts are arranged sequentially to form the standard RoCEv2 protocol encapsulation. The middle layer provides a detailed expansion of the IP header (IPv6), displaying the three fields of the standard IPv6 header: a 4-digit version field, an 8-digit traffic category field, and a 20-digit flow label field, from left to right. Below this layer, it is noted that the standard IPv6 header is compatible with RoCEv2, indicating that this invention reuses fields while maintaining compatibility with standard protocols. The bottom layer further subdivides the flow label field, dividing the 20-bit field into two logical areas: the left side is for the security check code or security cookie, occupying 4 bits, and the right side is for the direct index, occupying 16 bits. The security check code is used for authentication or verification, and the direct index is used to point to the physical memory offset, i.e., the context slot. Below this layer, the label is carried by the IPv6 flow label, which contains a total of 20 bits, and the bit range is further marked as bits 19 to 16 for the check code and bits 15 to 0 for the direct index. This structural design embodies the functional reuse and redefinition of the standard 20-bit flow label field in the IPv6 header. The high 4 bits serve as a security check code area to carry a random check code assigned by the receiving end. During parsing, the receiving end hardware forces a comparison of this field for authentication and tenant isolation, preventing malicious attackers from accessing the context memory of other connections out of bounds by forging indexes. The low 16 bits serve as a direct index area to carry index information pointing to a specific slot in the fast context pool. When the receiving end network card receives a RoCEv2 data packet carrying this flow label, it can directly parse the index information from the label and locate the corresponding slot in the fast context pool for context reading or updating. Since the slots are organized in physical memory in a predetermined way into a directly computable access structure, this process does not require traditional hash lookups or collision traversals, thus effectively achieving low-overhead, low-latency context acquisition and packet processing. At the same time, through the hybrid encoding format of security check codes and direct indexes, high-performance addressing and memory security protection are balanced within the limited packet header fields.

[0052] Step S30: Parse the target data packet to obtain the target flow identifier information, and verify the target flow identifier information to obtain the target verification result. It should be noted that the target flow identifier information is the flow identifier information parsed and extracted by the receiving end from the returned target data packet. This information has the same format and content as the initial flow identifier information encapsulated by the sending end, and is the direct basis for the receiving end to perform physical addressing and security verification. This information is accurately extracted from the programmable field in the packet header. The extraction process is completed by the hardware parsing engine of the receiving end's network card, which has higher processing efficiency compared to software parsing.

[0053] Additionally, it should be noted that the InfiniBand Base Transport Header (IBBTH) is a field in the RoCEv2 message structure that carries the core transmission information of the InfiniBand protocol. It is located after the UDP header and before the data payload. It is an essential component of the standard RoCEv2 protocol encapsulation and together with the Ethernet header, IP header, and UDP header, constitutes the basic header structure of the RoCEv2 message.

[0054] Additionally, the target verification result is obtained by the receiving end performing a hardware-level comparison between the security verification information in the parsed target stream identifier information and the corresponding locally configured verification information. There are only two clear results: verification passed and verification failed.

[0055] Understandably, the dual-mode parsing engine of the receiving network card performs a complete parsing of the received target data packet, extracts the target flow identification information from the programmable field in the packet header, separates the security verification information in the identifier, performs a hardware-level precise comparison with the verification information configured locally for the connection, and obtains the target verification result based on the comparison result.

[0056] In one feasible implementation, step S30 may include steps A31 to A32: Step A31, parsing the target data packet to obtain the offset index and security verification information; it should be noted that the target data packet is a converged Ethernet remote direct memory access version 2 data packet formed by the sending end embedding the initial flow identification information into the programmable field of the packet header. The offset index and security verification information are encoded and stored in the designated field of the packet, which is the core carrier for data transmission and addressing information.

[0057] In this embodiment, the addressing information of the target data packet is encapsulated in a specific bit field of the IPv6 flow label field or the UDP source port, which can be quickly identified and extracted by the hardware parsing engine.

[0058] Additionally, the offset index is the physical offset information pointing to the context slot in the fast context pool. This information corresponds one-to-one with the free slots in the fast context pool and is the core data for locating the physical storage location of the connection context. In this embodiment, this information is encoded in the programmable field of the message header in the form of a fixed bit field.

[0059] Additionally, the security verification information is a checksum randomly generated by the receiving end for the target connection, used for authentication and legitimacy verification. This information is crucial for preventing malicious attacks and unauthorized access due to index out-of-bounds errors. It is encoded together with the offset index in a designated field of the message according to preset bit field rules and cannot be arbitrarily tampered with.

[0060] It is understandable that the dual-mode parsing engine performs hardware-level parsing on the received target data packets, extracts the encoded combination information from the programmable fields in the packet header, and splits the combination information into offset index and security check information according to the preset bit field division rules.

[0061] Step A32: Generate target flow identification information based on the offset index and the security verification information.

[0062] It is understandable that, according to the preset encoding format used by the sender when generating the initial stream identifier information, the bit fields of the split offset index and security check information are combined to generate the complete target stream identifier information.

[0063] In one feasible implementation, step S30 may include steps B31-B34: Step B31, obtaining the local security configuration; it should be noted that the local security configuration is security verification information randomly generated and stored locally by the receiving end when allocating context slots for the target connection, and serves as the basis for the receiving end to perform security verification and comparison operations. This configuration corresponds one-to-one with the target connection, and after being generated during the connection establishment phase, it is stored in the receiving end's dedicated configuration register. It is only used to match the security verification operations of the corresponding target connection and will not be arbitrarily modified or misappropriated.

[0064] Understandably, before performing security verification on the target flow identification information, the local security configuration pre-configured and stored for the target connection is retrieved from the local dedicated configuration register to prepare benchmark data for subsequent verification and comparison operations.

[0065] Step B32: Perform security verification on the target flow identification information to obtain security verification information of the target flow identification information. It should be noted that the security verification information is information extracted from the target flow identification information for authentication and legitimacy verification. This information is obtained by the sending end from the receiving end and embedded into the target data packet along with the target flow identification information. It is encoded together with the offset index in the target flow identification information according to fixed bit field rules.

[0066] Understandably, hardware-level splitting operations are performed on the parsed complete target stream identifier information, and the corresponding security verification information is extracted from the target stream identifier information according to the preset bit field partitioning rules, thus completing the pre-processing of security verification of the target stream identifier information.

[0067] Step B33 involves determining whether the security verification information of the target flow identifier is the same as the local security configuration. This means performing a hardware-level bit-by-bit comparison between the security verification information extracted from the target flow identifier and the local security configuration retrieved from the local configuration register. Based on the result of this bit-by-bit comparison, it is determined whether the two contents are completely identical, thus obtaining the corresponding comparison result. In this embodiment, if the local security configuration is 0x3, and the security verification information extracted from the target flow identifier 0x30005 is also 0x3, then it is determined that the two contents are the same.

[0068] Step B34: When the security verification information of the target flow identifier information is the same as the local security configuration, the target verification result is determined to be a successful security verification.

[0069] Understandably, if after hardware-level bit-by-bit comparison it is determined that the security verification information extracted from the target flow identification information is completely consistent with the local security configuration content pre-configured for the target connection, then the target verification result for the target flow identification information will be judged as a successful security verification.

[0070] Step S40: Determine the target lookup strategy based on the target verification result, and determine the context physical address based on the target lookup strategy to complete the packet address lookup based on the flow identifier.

[0071] It should be noted that the target lookup strategy is the specific method selected by the receiving end to locate the context physical address based on the target verification result. It mainly includes two types: fast lookup path based on direct arithmetic calculation and traditional hash lookup path based on queue sequence number.

[0072] Additionally, the context physical address is the absolute storage address of the context corresponding to the target connection in physical memory. This address can be obtained through direct arithmetic calculation or traditional lookup methods and is crucial information for the receiving network card to directly access the connection context data. After obtaining this address, the receiving network card can directly initiate data prefetching operations without performing hash lookups or multi-level page table traversals, significantly reducing memory access latency.

[0073] Furthermore, the message address lookup based on the flow identifier is an addressing method in which the receiving end relies on the flow identifier information carried in the message to complete the context physical address location. This method takes the flow identifier as the core and abandons the traditional logic of relying on the hash lookup of sequence numbers by the queue and the multi-level page table conversion.

[0074] Understandably, if the target verification result is successful, the fast lookup path based on direct arithmetic calculation is selected, and the context physical address is calculated by adding the base address to the index and multiplying by the entry size; if the verification result is unsuccessful, the process falls back to the traditional hash lookup path based on the queue pair sequence number, and the context physical address is obtained through hash calculation and table lookup, thus completing this addressing.

[0075] Referring to Figure 4, Figure 4 is a schematic diagram of the direct index implementation logic-to-physical mapping, i.e., NPC concept, of the first embodiment of the message address lookup method based on flow identifier of this application.

[0076] It should be noted that NPC is a concept related to the mapping from logical address to physical address. It is used to characterize the conversion relationship between logical view and physical view in the direct indexing mechanism. Based on this concept, the mapping principle of discrete logical queues to sequence numbers to continuous physical offset indexes can be clearly explained. It is an auxiliary concept for understanding direct indexing addressing.

[0077] As shown in Figure 4, the overall structure is divided into three views from left to right: the logical view, the mapping (direct index allocation), and the physical memory view. This clearly illustrates the memory mapping principle of the direct index mechanism in this invention. In the leftmost logical view, the identification status of the three RDMA connections from the perspective of the operating system or application layer is displayed. From top to bottom, they are: connection A (any ID with queue pair number 1005), connection B (any ID with queue pair number 88), and connection C (any ID with queue pair number 4096). These values ​​exhibit high discreteness and disorder. The queue pair number (QPN) values ​​marked on the left are not continuous or randomly distributed in the logical space, indicating that directly using these logical QPNs as memory indexes in existing technologies would lead to significant memory waste or necessitate the use of complex hash tables for management. The rightmost physical memory view shows a contiguous storage area called contiguous physical memory or fast pool maintained by the receiving network card in physical memory, i.e., Dynamic Random Access Memory (DRAM) or Static Random Access Memory (SRAM). This memory pool consists of three fixed-size slots arranged linearly. From top to bottom, slot 0 stores the context of connection A with an address equal to the base address plus 0, slot 1 stores the context of connection B with an address equal to the base address plus 256, and slot 2 stores the context of connection C with an address equal to the base address plus 512. The right side of this section indicates that the linear contiguous layout achieves address calculation with an O(1) time complexity, which shows that direct access to physical memory can be achieved through a linear combination of the base address and the contiguous index. The figure also shows that the base address in the register points to the starting position of this fast pool.The intermediate mapping section, specifically the direct index allocation section, illustrates the conversion process from discrete QPNs to continuous indices. From top to bottom, the label index for connection A is 0, the label index for connection B is 1, and the label index for connection C is 2. Above this section, it's noted that the handshake process allocates indices in the continuous pool. This indicates that during the connection establishment negotiation phase, the driver establishes a static mapping relationship from discrete QPNs to continuous indices, mapping logical QPN 1005 to physical layer index 0, logical QPN 88 to physical layer index 1, and so on. 4096 is mapped to physical layer index 2. Through this mapping, the receiver sends the generated index to the sender via a negotiation message. When the receiver receives a message carrying the index, the hardware logic does not need to be aware of the original logical QPN of the message, nor does it need to traverse the hash table. Instead, it directly uses the formula that the physical address is equal to the base address plus the index multiplied by the step size to locate the corresponding slot in the physical view. The step size is equal to 256 bytes. This formula is clearly marked at the bottom of the figure. For example, if the base address is a fixed value and the index is 1, the hardware adder directly calculates the physical address of the target context as the base address plus 256. The whole process completely bypasses the uncertainty waiting caused by hash collision handling and cache miss, successfully transforming the logical sparse search problem into a physical linear calculation problem, thereby realizing O(1) complexity context access.

[0078] Referring to Figure 5, Figure 5 is a comparative schematic diagram of the traditional RoCEv2 hash lookup and the proposed message address lookup scheme based on flow identifier in the first embodiment of the message address lookup method based on flow identifier of this application.

[0079] As shown in Figure 5, the whole is divided into two parts: the left side represents the existing technology, RoCEv2 hash lookup, and the right side represents the proposed solution, which is packet address lookup based on flow identifiers. In the existing technology section on the left, the inbound packet carries the information that the queue pair sequence number is equal to X and enters the receiving end network card. First, it passes through the processing node that calculates the hash, i.e., Hash (QPN). This node performs a hash operation on the queue pair number and then outputs it to the hash table for lookup. The hash table is presented in a grid form, representing the data structure that stores hash mapping relationships. When a hash collision occurs, a linked list traversal operation is required. In the figure, the linked list structure is represented by stacked cylinders, showing the collision resolution mechanism. Finally, the context is obtained from the system memory. However, this process has high latency, and the overall process is marked as a multi-step lookup. The figure uses tangled lines to visually represent the complexity and uncertainty of the hash lookup path. In the right-hand section of this solution, the inbound packet carrying the flow label equal to the label information enters the receiving network card. It first passes through a splitter or demultiplexer module, which splits the flow label into two components: a checksum and an index. The checksum is used for security verification, and the index is used for physical address location. The split index and the value in the base address register are input to the direct physical address calculation module. This module is represented by an adder symbol and performs an arithmetic operation of adding the base address to the index multiplied by the entry size. The result points to a specific slot in the fast context pool. The diagram shows the physical memory pool structure represented by three stacked rectangles. Finally, the context is obtained and marked as low latency, and the entire process is marked as a one-step indexing, which intuitively demonstrates the deterministic low latency characteristics of this solution by replacing traditional hash lookup with direct arithmetic calculation.

[0080] In one feasible implementation, steps S401 to S403 may be included before step S40: Step S401, when the number of current cluster connections exceeds the preset flow identifier range, the target connections are sorted according to the connection activity to obtain the cluster connection sorting; it should be noted that the current number of cluster connections refers to the total number of established Remote Direct Memory Access (RDMA) connections in the current high-performance computing or artificial intelligence cluster. This number will change dynamically with the service operation status of the cluster and is the basic data for determining whether hardware resource allocation is required. When this number exceeds the limit range, the subsequent connection sorting operation will be triggered.

[0081] Additionally, the preset flow identifier range is a threshold for the maximum number of connections that the flow identifier can support, which is preset based on the bit field length of the programmable field in the message header.

[0082] In this embodiment, if the 20-bit stream tag field of the Internet Protocol version 6 header is used, this range is determined by the bit field encoding capability of the field and is the core criterion for triggering the connection sorting process.

[0083] In addition, connection activity is an indicator that measures the frequency of service transmission of each target connection within the cluster. It can be comprehensively judged based on actual business dimensions such as the frequency of message transmission and the amount of data transmitted. It is the only basis for ranking target connections. Connections with higher activity are more suitable for processing through fast addressing paths.

[0084] In addition, cluster connection sorting is a connection sequence obtained by sorting all target connections in the cluster according to the order of connection activity from high to low. This sequence can clearly distinguish between high-activity connections and low-activity connections, providing a direct and clear basis for subsequent hardware resource allocation and traffic distribution operations.

[0085] Understandably, the total number of RDMA connections in the current cluster is detected in real time, and it is determined whether the number exceeds the preset flow identifier range. If the detection result is that it exceeds the limit, the connection activity of each target connection in the cluster is extracted, and all target connections are sorted in descending order of activity to obtain the corresponding cluster connection sort.

[0086] Step S402: Map the target connections whose cluster connection order is greater than or equal to a preset sequence number threshold to context slots; it should be noted that the preset sequence number threshold is a sorting sequence number limit pre-set based on the total number of context slots in the fast context pool, and the value of this threshold matches the hardware storage resource capacity of the fast context pool.

[0087] Additionally, the context slot is a pre-defined, physically contiguous, fixed-size storage location within the fast context pool. It is specifically designed to store the context state information of highly active target connections, supports direct physical addressing access by the network interface card (NIC) hardware, and serves as the physical carrier for implementing direct indexing and fast addressing of flow identifiers.

[0088] Understandably, a preset sequence number threshold that matches the number of slots in the fast context pool is pre-set. Target connections with a sorting result greater than or equal to the preset sequence number threshold are selected from the obtained cluster connection sorting. These highly active target connections are then mapped one by one to the idle context slots in the fast context pool, establishing a deterministic mapping relationship between highly active connections and context slots.

[0089] Step S403: Store the target connections whose cluster connection order is less than the preset sequence number threshold into a preset hash table structure for hardware resource allocation.

[0090] It should be noted that the default hash table structure is a traditional data structure that is pre-configured to store the context information of low-activity target connections. This structure is adapted to the hash lookup path based on the sequence number of the queue and is a dedicated storage structure for storing the context of low-activity connections. It is compatible with conventional message processing logic.

[0091] Additionally, hardware resource offloading refers to allocating different target connections to two different hardware storage resources—a fast context pool and a preset hash table structure—based on the activity level of the target connection. This separates high-activity connections from low-activity connections, thereby achieving a reasonable allocation and utilization of limited hardware resources.

[0092] It should be noted that hardware resource allocation is a resource allocation method that separates high-activity connections from low-activity connections by allocating different target connections to two different hardware storage resources: a fast context pool and a preset hash table structure, based on the activity level of the target connection. The core purpose is to maximize performance with limited hardware storage resources, allowing high-priority, high-activity connections to use fast addressing resources, while low-activity connections use traditional hash table resources.

[0093] Understandably, target connections with sorting results less than a preset sequence number threshold are selected from the cluster connection sorting. The context information of these low-activity target connections is uniformly stored in a pre-configured preset hash table structure. In this way, target connections with different activity levels are allocated to different hardware storage resources, thus completing the hardware resource distribution operation within the cluster.

[0094] In one feasible implementation, step S40 may include steps S41 to S43: Step S41, when the target verification result is that the security verification is passed, the target lookup strategy is determined to be the flow identifier lookup strategy; it should be noted that the flow identifier lookup strategy is a fast lookup method that relies on the flow identifier information carried in the packet to complete the context physical address location, which can also be called direct arithmetic calculation lookup path. This strategy abandons the traditional hash lookup and multi-level page table traversal logic, and achieves address location with constant time complexity. It is specifically used to handle the packet addressing requirements of latency-sensitive high-priority connections.

[0095] Understandably, after determining that the target verification result is a security verification pass, the target lookup strategy for this packet address lookup is set to the flow identifier lookup strategy, and subsequent related operations for fast addressing are initiated.

[0096] Step S42: Determine the fast pool base address register value, context entry size, and offset index in the target flow identifier information according to the flow identifier lookup strategy. It should be noted that the fast pool base address register value is the fast context pool base address value pre-configured in the dedicated register of the receiving end network card. This value is the starting address of the fast context pool in physical memory and is the basic reference value for calculating the context physical address.

[0097] In this embodiment, the value of the fast pool base address register can be 0x10000000. This value is persistently stored in a dedicated register and can be quickly retrieved by the receiving network card for address calculation.

[0098] Additionally, the context entry size is a fixed number of bytes stored in each context slot in the fast context pool. This value is a pre-set fixed value and is the offset step size when calculating the context physical address.

[0099] In this embodiment, the context entry size can be 256 bytes. This value matches the slot design of the fast context pool and will not change with connection state.

[0100] Understandably, after determining that the flow identifier lookup strategy should be adopted, the fast pool base address register value and context entry size are retrieved from the receiving end network card, and the corresponding offset index is extracted from the target flow identifier information.

[0101] Step S43: Calculate the context physical address based on the value of the fast pool base address register, the size of the context entry, and the offset index to complete the packet address lookup based on the flow identifier.

[0102] It should be noted that address calculation is the operation by which the receiving network card obtains the context physical address through hardware arithmetic operations. This operation is performed by the address calculation unit of the network card and can be completed with only simple arithmetic operations. No table lookup or traversal operation is required. The hardware-level processing makes this operation extremely time-consuming.

[0103] Additionally, the context physical address is the absolute storage address of the context corresponding to the target connection in physical memory. This address is key information for the receiving network card to directly access the connection context data. After obtaining this address, the network card can directly initiate a data prefetch operation to process packets without additional memory access operations.

[0104] Furthermore, message address lookup based on flow identifiers is an addressing method that uses flow identifier information to perform context physical address location through direct arithmetic calculation. This method achieves address lookup with constant time complexity, completely eliminating performance jitter caused by long-tail latency and hash collisions, and meeting the requirements of high-performance computing for deterministic latency.

[0105] Understandably, by combining the value of the fast pool base address register, the size of the context entry, and the offset index, hardware arithmetic operations are performed to calculate the context physical address, thus completing this packet address lookup based on the flow identifier.

[0106] In this embodiment, it is assumed that node A (sender) needs to send data to node B (receiver).

[0107] During the connection establishment phase, Node B identifies the connection as belonging to a latency-sensitive, high-priority training task. Node B's driver requests a free context slot for this connection from a pre-built contiguous "fast context pool" in physical memory (e.g., at base address 0x1000_0000). Assume the system allocates a context object in the 5th slot of the fast pool (each slot is a fixed size, e.g., 256 bytes) and simultaneously allocates or generates a checksum for security verification (e.g., 0x3). Node B encodes these two pieces of information into a stream tag, calculated as Tag = (0x3<<16) | 5 = 0x30005 (i.e., the high 4 bits are the checksum, and the low 16 bits are the index). Subsequently, Node B returns this tag to the sending node A via an RDMA connection establishment response message (CM Response). Upon receiving this, Node A records the tag in its local connection context information and associates it with the target QP.

[0108] During the data transmission phase, Node A's network interface card (NIC) reads the pre-stored Tag information from the connection context and fills it into the programmable field of the packet header when encapsulating RoCEv2 packets. This invention makes specific improvements to the standard RoCEv2 packet structure: taking the IPv6 header as an example, the 20-bit Flow Label field, which is typically ignored or only used for ECMP hash calculations in existing technologies, is reused as two independent functional areas. The high 4 bits are used to carry a security checksum (cookie, e.g., 0011, which is 0x3), and the low 16 bits are used to carry a direct index (e.g., 00000000 0000 0101 pointing to the 5th slot). As an alternative embodiment, this mechanism can also reuse the Source Port field of the UDP header, using its low 12 bits to carry the index and the high 4 bits to reserve the hash entropy required for network-side ECMP load balancing.

[0109] When Node B's network interface card (NIC) receives a packet, the hardware parsing engine performs a "packet parsing and flow splitting" operation, checking whether the IPv6 Flow Label field carries a specific identifier (or is non-zero). If the extracted Flow Label is 0x30005, the hardware logic immediately splits it into a checksum of 0x3 and an index of 5. Subsequently, the system performs hardware-level security verification, comparing the extracted cookie with the configuration register value corresponding to the current fast pool; only if the verification passes is the packet confirmed as a legitimate "fast flow" and enters the direct addressing path; otherwise, it falls back to the conventional hash lookup path. In the address calculation stage, this invention uses deterministic arithmetic addressing logic instead of traditional hash table lookup logic. The receiving NIC hardware directly executes the physical address calculation formula: Physical Address = Fast Pool Base Address Register Value + (Index × Entry Size). Taking a specific numerical example, if the Fast Pool Base Address Register value is 0x1000_0000, the parsed index is 5, and the hardware default stride size is 256 bytes, then the hardware adder directly calculates the physical address of the target context as 0x1000_0500. Finally, the network card DMA engine directly reads the QP context data from the host memory based on this calculated address to process the packet. The entire process completely bypasses the uncertainties caused by hash collision handling and cache misses, achieving deterministic latency below the microsecond level.

[0110] This embodiment provides a message address lookup method based on flow identifiers. By allocating context slots for latency-sensitive services and generating flow identifiers containing indexes and checksums during the connection establishment phase, and passing them to the sending end for embedding in the message field after out-of-band negotiation, the receiving end parses and verifies the identifiers and directly locates the physical address based on the arithmetic operation of the base address plus the index multiplied by the entry size, this method solves the technical problems of multi-step traversal, long-tail latency due to cache misses, and hash collisions caused by the traditional RoCEv2's reliance on hash lookups. It achieves the beneficial effects of deterministic low-latency context acquisition, eliminating performance jitter, and supporting ultra-high-speed network line-speed forwarding.

[0111] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to Figure 6. Step S10 of the packet address lookup method based on flow identifier includes steps S11 to S13: Step S11, when a target connection establishment request is detected, the service type of the target connection is determined; it should be noted that the service type is a classification of the services corresponding to the target connection based on actual business dimensions such as data transmission latency requirements and service importance. The core purpose of this classification is to distinguish the service transmission requirements of different priorities, which is the core basis for determining whether to allocate dedicated resources of the fast context pool to the target connection.

[0112] Understandably, it involves real-time detection of whether a target connection establishment request has been received. Upon detection of such a request, it identifies and determines the actual service corresponding to the target connection, thus clearly defining the service type to which the target connection belongs.

[0113] Step S12: When the service type is a first priority service, a context slot and security verification information are allocated to the target connection to obtain index information and security verification information. It should be noted that the first priority service is a latency-sensitive service with strict requirements on the deterministic latency of data transmission, and it is the service type with the highest processing priority among all service types.

[0114] Additionally, context slots are pre-allocated physical contiguous and fixed-size storage locations within the fast context pool. Each slot corresponds to a unique physical offset and is specifically used to store the context state information of the target connection corresponding to the first priority service. It is the dedicated physical storage carrier for the context of this type of connection.

[0115] Understandably, after determining that the service type of the target connection is a first-priority service, an idle context slot is allocated for the target connection in the fast context pool, and security verification information is randomly generated for the target connection. The corresponding index information is then extracted from the slot allocation result.

[0116] In one feasible implementation, step S12 may include steps S121 to S123: Step S121, when the service type is a first priority service, determine the context slot in the physical memory area; it should be noted that the physical memory area is a contiguous fast context pool pre-built in physical memory. This area is specially planned as an exclusive area for storing the target connection context state information corresponding to the first priority service. It consists of multiple fixed-size storage locations arranged linearly, supports direct physical addressing access by the network card hardware, and is the core physical space for allocating storage resources for high priority services.

[0117] Understandably, after determining that the service type of the target connection is a first-priority service, an unoccupied free storage location is selected from the pre-built dedicated physical memory area, and this free storage location is determined as the context slot allocated to the target connection.

[0118] Step S122: Determine the storage location of the target connection in the context slot and generate index information. It should be noted that the storage location is a specific physical location in the context slot specifically used to store the target connection context state information. This location has a fixed offset relationship with the base address of the physical memory region. It is the specific basis for accurately locating the target connection context data and is directly related to subsequent physical address calculation operations.

[0119] Understandably, based on the determined context slot, the specific storage location of the target connection's context state information in that slot is determined, and based on the fixed offset relationship between that storage location and the base address of the physical memory region, index information uniquely corresponding to the target connection is generated.

[0120] Step S123: Generate a security check code according to the random generation strategy to obtain security check information.

[0121] It should be noted that the random generation strategy is a pre-defined checksum generation rule to prevent malicious attacks and unauthorized access by index out-of-bounds. The checksum generated according to this rule is random and unique. The same target connection corresponds to a unique checksum and cannot be easily forged. It is the core generation rule to ensure memory security during the direct addressing process.

[0122] In addition, the security check code is a unique code randomly generated for the target connection according to a random generation strategy, used for authentication and legitimacy verification. This code corresponds one-to-one with the target connection and is the key comparison basis for the receiving end to determine whether the message is legitimate.

[0123] Furthermore, security verification information is legality verification data with security verification code as its core. It is the direct object compared with local configuration information when performing security verification on the target flow identification information, and carries the core functions of identity verification and illegal access identification.

[0124] Understandably, a unique security check code is randomly generated for the target connection according to a pre-set random generation strategy, and this generated security check code is used as the security verification information corresponding to the target connection.

[0125] Step S13: Combine and encode the index information and the security verification information to obtain the initial flow identifier information.

[0126] It should be noted that the combined encoding is an operation that integrates and encodes index information and security verification information according to a preset bit field partitioning rule. This operation will allocate fixed bit field intervals to the two types of information respectively, ensuring that the unified identifier after encoding can be accurately split and decoded in the future. It is the core operation for generating a single stream identifier.

[0127] Understandably, according to the preset bit field encoding rules, the index information and security verification information obtained for the target connection are integrated and encoded, and the corresponding preset bit field intervals are assigned to the two types of information to generate complete initial stream identification information.

[0128] This embodiment provides a message address lookup method based on flow identifiers. By first determining the service type when a target connection establishment request is detected, and allocating context slots in the physical memory area only for first-priority services, generating index information and random security check codes, and combining and encoding them to obtain the initial flow identifier, this method solves the technical problem in the prior art where uniform processing of all connections leads to the occupation of fast context pool resources by low-priority services and high-priority services being unable to obtain deterministic low-latency services. This method achieves the beneficial effects of enabling hierarchical processing of services, prioritizing the performance of latency-sensitive services, and improving the efficiency of hardware resource utilization.

[0129] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the message address lookup method based on flow identifiers in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0130] This application also provides a packet address lookup device based on flow identifiers. Referring to Figure 7, the packet address lookup device based on flow identifiers includes: an identifier generation module 10, used to allocate context slots and security verification information to the target connection when a target connection establishment request is detected, obtain index information and verification information, and generate initial flow identifier information based on the index information and the verification information; a packet receiving module 20, used to send the initial flow identifier information to the sending end through the target connection, so that the sending end generates a target data packet based on the initial flow identifier information and feeds it back; an identifier verification module 30, used to parse the target data packet, obtain the target flow identifier information, and verify the target flow identifier information to obtain a target verification result; and an address lookup module 40, used to determine a target lookup strategy based on the target verification result and determine the context physical address based on the target lookup strategy to complete the packet address lookup based on flow identifiers.

[0131] The flow identifier-based packet address lookup device provided in this application, employing the flow identifier-based packet address lookup method in the above embodiments, can solve the technical problem that the existing RoCEv2 receiver's connection context location process relies on a complex lookup mechanism, resulting in unpredictable packet processing latency and significant long-tail latency in high-concurrency scenarios. Compared with the prior art, the beneficial effects of the flow identifier-based packet address lookup device provided in this application are the same as those of the flow identifier-based packet address lookup method provided in the above embodiments, and other technical features in the flow identifier-based packet address lookup device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0132] In one embodiment, the identifier generation module 10 is further configured to determine the service type of the target connection when a target connection establishment request is detected; when the service type is a first priority service, allocate context slots and security verification information to the target connection to obtain index information and security verification information; and combine and encode the index information and the security verification information to obtain initial flow identifier information.

[0133] In one embodiment, the identifier generation module 10 is further configured to: determine a context slot in the physical memory region when the service type is a first priority service; determine the storage location of the target connection in the context slot and generate index information; and generate a security check code according to a random generation strategy to obtain security check information.

[0134] In one embodiment, the address lookup module 40 is further configured to: determine the target lookup strategy as a flow identifier lookup strategy when the target verification result is a security verification pass; determine the fast pool base address register value, the context entry size, and the offset index in the target flow identifier information according to the flow identifier lookup strategy; and perform address calculation based on the fast pool base address register value, the context entry size, and the offset index to obtain the context physical address, thereby completing the packet address lookup based on the flow identifier.

[0135] In one embodiment, the identifier verification module 30 is further configured to parse the target data packet to obtain an offset index and security verification information; and generate target flow identifier information based on the offset index and the security verification information.

[0136] In one embodiment, the identifier verification module 30 is further configured to: obtain a local security configuration; perform security verification on the target flow identifier information to obtain security verification information of the target flow identifier information; determine whether the security verification information of the target flow identifier information is the same as the local security configuration; and when the security verification information of the target flow identifier information is the same as the local security configuration, determine that the target verification result is a successful security verification.

[0137] In one embodiment, the address lookup module 40 is further configured to, when detecting that the number of current cluster connections exceeds the preset flow identifier representation range, sort the target connections according to the connection activity to obtain a cluster connection sort; map the target connections whose cluster connection sort is greater than or equal to a preset sequence number threshold to a context slot; and store the target connections whose cluster connection sort is less than the preset sequence number threshold to a preset hash table structure for hardware resource distribution.

[0138] This application provides a packet address lookup device based on flow identifiers. The packet address lookup device based on flow identifiers includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the packet address lookup method based on flow identifiers in the first embodiment described above.

[0139] Referring now to Figure 8, a schematic diagram of a flow-identifier-based packet address lookup device suitable for implementing embodiments of this application is shown. The flow-identifier-based packet address lookup device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. The flow-identifier-based packet address lookup device shown in Figure 8 is merely an example and should not impose any limitations on the functionality and scope of use of embodiments of this application.

[0140] As shown in Figure 8, the stream identifier-based message address lookup device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in ROM (Read Only Memory) 1002 or a program loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the stream identifier-based message address lookup device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the flow identifier-based message address lookup device to communicate wirelessly or wiredly with other devices to exchange data. Although flow identifier-based message address lookup devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0141] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0142] The flow identifier-based packet address lookup device provided in this application, employing the flow identifier-based packet address lookup method in the above embodiments, can solve the technical problem that the existing RoCEv2 receiver's connection context location process relies on a complex lookup mechanism, resulting in unpredictable packet processing latency and significant long-tail latency in high-concurrency scenarios. Compared with the prior art, the beneficial effects of the flow identifier-based packet address lookup device provided in this application are the same as those of the flow identifier-based packet address lookup method provided in the above embodiments, and other technical features in this flow identifier-based packet address lookup device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0143] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0145] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the message address lookup method based on flow identifier in the above embodiments.

[0146] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (EPROM), optical fiber, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0147] The aforementioned computer-readable storage medium may be included in a flow identifier-based packet address lookup device; or it may exist independently and not assembled into a flow identifier-based packet address lookup device.

[0148] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a flow-identifier-based packet address lookup device, the flow-identifier-based packet address lookup device: upon detecting a target connection establishment request, allocates a context slot and security verification information for the target connection, obtains index information and verification information, and generates initial flow identification information based on the index information and the verification information; sends the initial flow identification information to a sending end through the target connection, so that the sending end generates a target data packet based on the initial flow identification information and provides feedback; parses the target data packet to obtain target flow identification information, verifies the target flow identification information, and obtains a target verification result; determines a target lookup strategy based on the target verification result, and determines the context physical address based on the target lookup strategy, thereby completing the flow-identifier-based packet address lookup.

[0149] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0150] 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 indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated 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 the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0151] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0152] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described flow identifier-based packet address lookup method. This solves the technical problem that existing RoCEv2 receivers rely on complex lookup mechanisms for locating connection contexts, leading to unpredictable packet processing delays and significant long-tail latency in high-concurrency scenarios. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the flow identifier-based packet address lookup method provided in the above embodiments, and will not be repeated here.

[0153] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described message address lookup method based on flow identifier.

[0154] The computer program product provided in this application can solve the technical problem that the existing RoCEv2 receiver relies on a complex lookup mechanism for locating the connection context, resulting in unpredictable message processing latency and significant long-tail latency in high-concurrency scenarios. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the message address lookup method based on flow identifiers provided in the above embodiments, and will not be repeated here.

[0155] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A packet address lookup method based on flow identifiers, characterized in that, The method includes: upon detecting a target connection establishment request, allocating a context slot and security verification information to the target connection to obtain index information and verification information, and generating initial flow identifier information based on the index information and the verification information; sending the initial flow identifier information to a sending end through the target connection, so that the sending end generates a target data packet based on the initial flow identifier information and sends it back; parsing the target data packet to obtain the target flow identifier information, and verifying the target flow identifier information to obtain a target verification result; determining a target lookup strategy based on the target verification result, and determining the context physical address based on the target lookup strategy to complete the packet address lookup based on the flow identifier.

2. The method as described in claim 1, characterized in that, The step of allocating context slots and security verification information to the target connection when a target connection establishment request is detected, obtaining index information and verification information, and generating initial flow identification information based on the index information and the verification information includes: determining the service type of the target connection when a target connection establishment request is detected; allocating context slots and security verification information to the target connection when the service type is a first priority service, obtaining index information and security verification information; and combining and encoding the index information and the security verification information to obtain initial flow identification information.

3. The method as described in claim 2, characterized in that, When the service type is a first-priority service, the step of allocating a context slot and security verification information to the target connection to obtain index information and verification information includes: when the service type is a first-priority service, determining a context slot in the physical memory area; determining the storage location of the target connection in the context slot and generating index information; generating a security verification code according to a random generation strategy to obtain security verification information.

4. The method as described in claim 1, characterized in that, The steps of determining a target lookup strategy based on the target verification result and determining the context physical address based on the target lookup strategy to complete the packet address lookup based on the flow identifier include: when the target verification result is a security verification pass, determining the target lookup strategy as a flow identifier lookup strategy; determining the fast pool base address register value, the context entry size, and the offset index in the target flow identifier information based on the flow identifier lookup strategy; and performing address calculation based on the fast pool base address register value, the context entry size, and the offset index to obtain the context physical address, thereby completing the packet address lookup based on the flow identifier.

5. The method as described in claim 1, characterized in that, The steps of parsing the target data packet to obtain target flow identification information include: parsing the target data packet to obtain offset index and security verification information; and generating target flow identification information based on the offset index and the security verification information.

6. The method as described in claim 1, characterized in that, The steps for verifying the target flow identifier information and obtaining the target verification result include: obtaining a local security configuration; performing security verification on the target flow identifier information to obtain security verification information of the target flow identifier information; determining whether the security verification information of the target flow identifier information is the same as the local security configuration; and determining that the target verification result is a successful security verification when the security verification information of the target flow identifier information is the same as the local security configuration.

7. The method as described in claim 1, characterized in that, Before the step of determining the target lookup strategy based on the target verification result and determining the context physical address based on the target lookup strategy to complete the packet address lookup based on the flow identifier, the method further includes: when the number of current cluster connections exceeds the preset flow identifier representation range, sorting the target connections according to the connection activity to obtain the cluster connection sort; mapping the target connections whose cluster connection sort is greater than or equal to a preset sequence number threshold to the context slot; and storing the target connections whose cluster connection sort is less than the preset sequence number threshold to a preset hash table structure for hardware resource allocation.

8. A packet address lookup device based on flow identifiers, characterized in that, The apparatus includes: an identifier generation module, configured to allocate context slots and security verification information to the target connection when a target connection establishment request is detected, obtain index information and verification information, and generate initial flow identifier information based on the index information and the verification information; a packet receiving module, configured to send the initial flow identifier information to a sending end through the target connection, so that the sending end generates a target data packet based on the initial flow identifier information and provides feedback; an identifier verification module, configured to parse the target data packet to obtain target flow identifier information, and verify the target flow identifier information to obtain a target verification result; and an address lookup module, configured to determine a target lookup strategy based on the target verification result, and determine the context physical address based on the target lookup strategy, so as to complete the packet address lookup based on the flow identifier.

9. A packet address lookup device based on flow identifiers, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the message address lookup method based on flow identifier as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the packet address lookup method based on flow identifier as described in any one of claims 1 to 7.

Images