A RoCEv2 overlay virtual network construction method and data processor

Abstract

This invention provides a RoCEv2 overlay virtual network construction method and data processor, relating to the field of data center network virtualization technology. The method includes: receiving RoCEv2 packets and obtaining tenant network configurations; parsing and extracting RDMA semantics such as queue pair identifiers and operation types, and combining them with tenant identifiers to form service semantic identifiers; establishing a correspondence between RDMA connections and overlay virtual network identifiers; encapsulating and decapsulating according to the correspondence and adding semantic extension fields; performing transmission scheduling based on semantics and network status; and implementing resource binding isolation control according to policies. The beneficial effect is that by perceiving RDMA connection semantics at the DPU side, the overlay network construction accurately distinguishes service flows, enabling fine-grained processing of intra-tenant connections and improving the virtual network's adaptability to service transmission semantics.

Description

Technical Field

[0001] This invention relates to the field of central network virtualization technology, and in particular to a RoCEv2 overlay virtual network construction method and data processor. Background Technology

[0002] With the rapid development of cloud computing, distributed storage, artificial intelligence training, and high-performance computing, RDMA technology, due to its characteristics of low latency, low CPU usage, and high throughput, has gradually become an important communication method for high-performance data center services. Among them, RoCEv2, as an RDMA implementation based on Ethernet and UDP / IP, can transmit RDMA services in a three-layer network and is therefore widely used in multi-node computing, distributed training, and high-performance storage systems.

[0003] On the other hand, to achieve multi-tenant isolation, network elastic scaling, unified orchestration, and decoupling of logical and physical networks, data centers typically employ overlay virtual network technologies based on protocols such as VXLAN. By adding tunnel encapsulation to the original service packets, logical isolation can be achieved for different tenant services on a shared physical network. With the development of data processor (DPU) or smart NIC technology, more and more network encapsulation, forwarding, filtering, rate limiting, and security isolation functions are being offloaded to the DPU side to reduce the host CPU load and improve network processing efficiency.

[0004] However, most existing solutions combining RoCEv2 with overlay virtual networks primarily focus on tunnel encapsulation and policy forwarding at the level of ordinary IP flows or virtual network interface cards (NICs). They typically rely on tenant identifiers, virtual machine identifiers, virtual functions (VFs), or ordinary flow tables to manage forwarding paths, while underutilizing RDMA semantic information carried within RoCEv2 packets, such as queue pair identifiers (QP_ID), operation types (Opcodes), and memory access contexts. Due to the lack of RDMA semantic recognition and association, existing solutions often only implement isolation and scheduling at a coarse-grained level, making it difficult to perform more targeted processing based on different RDMA connections and operation types. Therefore, it is necessary to provide a technical solution that introduces an RDMA semantic awareness mechanism at the data processor (DPU) level to improve the adaptability and deployability of RoCEv2 services in multi-tenant overlay network environments. Summary of the Invention

[0005] To address the problems existing in the prior art, this invention provides a RoCEv2 overlay virtual network construction method, applied to a data processor, comprising: Step S1: The data processor receives the RoCEv2 message and obtains the network configuration information associated with the current tenant; Step S2: The data processor parses the RoCEv2 message, extracts RDMA semantic content including queue pair identifier and operation type, and forms a service semantic identifier based on the RDMA semantic content and the tenant identifier. Step S3: The data processor establishes or updates the correspondence between the RDMA connection and the overlay virtual network identifier based on the service semantic identifier; Step S4: The data processor applies superimposed encapsulation processing or decapsulation processing to the RoCEv2 message according to the correspondence, and adds a semantic extension field reflecting the semantic content of the RDMA to the encapsulated message; Step S5: The data processor combines the RDMA semantic content and the acquired network state parameters to perform semantic-driven transmission scheduling operations. Step S6: The data processor, based on the service semantic identifier and the corresponding relationship, implements resource binding and isolation control according to the resource configuration strategy issued by the control plane to complete the construction of the RoCEv2 overlay virtual network.

[0006] Preferably, the RDMA semantic content further includes one or more of the following: memory region identifier association information and message data length; The memory region identifier associated information is one of the following: a remote access key, a local access key, or an internal memory region identifier mapped from a remote access key or a local access key; The internal memory region identifier is obtained by the data processor by reading the access key field in the RoCEv2 message and retrieving the local memory region mapping table.

[0007] Preferably, the business semantic identifier is composed of the queue pair identifier, the tenant identifier, and the operation type; Alternatively, the business semantic identifier may be composed of at least one of the following: queue pair identifier, tenant identifier, operation type, memory region identifier association information, and data length.

[0008] Preferably, step S3 includes: The data processor checks whether there is an existing mapping record corresponding to the business semantic identifier. If there is no existing mapping record, it allocates a new overlay virtual network identifier based on the business semantic identifier and writes the business semantic identifier and the new overlay virtual network identifier into the mapping table.

[0009] Preferably, step S3 includes: Step S31: The data processor processes the business semantic identifier through a first hash operation to obtain a first candidate identifier; Step S32: When the first candidate identifier has been occupied by other business semantic identifiers, the data processor obtains the second candidate identifier through a second hash operation; Step S33: When the second candidate identifier is still in an occupied state, the data processor performs linear probing based on a preset step size; In step S34, if the data processor still fails to obtain an idle identifier within a preset threshold number of attempts, it sends a request to the control plane to obtain the specified overlay virtual network identifier.

[0010] Preferably, the process of applying overlay encapsulation to the RoCEv2 message in step S4 includes: The data processor encapsulates the RoCEv2 message using a standard VXLAN header and inserts a semantic extension header after the standard VXLAN header and before the original RoCEv2 message, using the semantic extension header to carry the semantic extension fields.

[0011] Preferably, the semantic extension field at least covers a queue pair identifier field, an operation type field, and a priority field, wherein the value of the priority field is determined based on at least one of the RDMA semantic content, tenant service level, and network state parameters.

[0012] Preferably, step S5 includes: The data processor generates a scheduling evaluation value based on explicit congestion notices, round-trip delays, queue depth, and operation weight factors corresponding to the operation type, and determines the target queue, priority parameters, or rate limit parameters based on the scheduling evaluation value.

[0013] Preferably, the resource allocation strategy in step S6 includes: At least one of the following: a tenant-overlay virtual network identifier binding strategy, an RDMA connection-queue resource binding strategy, a memory region access control strategy, a priority strategy, and a mapping entry aging strategy; The RoCEv2 overlay virtual network construction method further includes: releasing the corresponding mapping entry and overlay virtual network identifier when it is detected that the RDMA connection is closed, the mapping entry meets the preset idle condition, or the virtual network instance is revoked.

[0014] This invention also provides a data processor that applies the above-described RoCEv2 overlay virtual network construction method, comprising: The message parsing module is used to receive RoCEv2 messages and obtain network configurations related to tenants, as well as to perform parsing on RoCEv2 messages; The semantic identifier generation module, connected to the message parsing module, is used to extract RDMA semantic content containing queue pair identifiers and operation types from the parsing results, and generate business semantic identifiers in conjunction with tenant identifiers. The mapping management module connects to the semantic identifier generation module and is used to establish or update the correspondence between RDMA connections and overlay virtual network identifiers based on business semantic identifiers. The overlay processing module is connected to the mapping management module and is used to perform overlay encapsulation or decapsulation on RoCEv2 messages according to the corresponding relationship, and add semantic extension fields reflecting RDMA semantic content to the encapsulated messages. The scheduling control module is connected to the semantic identifier generation module and is used to perform semantic-driven transmission scheduling operations based on RDMA semantic content and network status parameters. The resource policy execution module connects the mapping management module and the overlay processing module. It is used to implement resource binding and isolation control based on the resource configuration policy issued by the control plane according to the business semantic identifier and the corresponding relationship, so as to realize the construction of RoCEv2 overlay virtual network.

[0015] The above technical solution has the following advantages or beneficial effects: By receiving RoCEv2 messages and obtaining network configuration on the data processor (DPU) side, parsing the messages to extract RDMA semantic content including queue pair identifiers and operation types, generating service semantic identifiers by combining tenant identifiers, and then establishing or updating the correspondence between RDMA connections and overlay virtual network identifiers based on these identifiers, the overlay encapsulation or decapsulation, scheduling control, and resource policy execution are completed, thereby forming a complete overlay virtual network construction link. This invention directly introduces RDMA connection semantics into the virtual network construction process, enabling the data processor (DPU) to perceive the connection context and operation type of the service. Therefore, it can more accurately distinguish different service flows and perform finer-grained processing on different connections within the same tenant, thereby improving the adaptability between services and the overlay virtual network and making the construction process closer to the transmission semantics of the service itself. Attached Figure Description

[0016] Figure 1 A flowchart illustrating a RoCEv2 overlay virtual network construction method is shown in a preferred embodiment of the present invention. Figure 2 A flowchart illustrating step S3 is shown in a preferred embodiment of the present invention. Figure 3 This is a schematic diagram of the structure of a data processor in a preferred embodiment of the present invention. Detailed Implementation

[0017] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. The present invention is not limited to this embodiment; other embodiments that conform to the spirit of the present invention may also fall within the scope of the present invention.

[0018] In a preferred embodiment of the present invention, based on the above-mentioned problems existing in the prior art, a RoCEv2 overlay virtual network construction method is provided, applied to a data processor, such as... Figure 1 As shown, it includes: Step S1: The data processor receives the RoCEv2 message and obtains the network configuration information associated with the current tenant; Step S2: The data processor parses the RoCEv2 message, extracts the RDMA semantic content including the queue pair identifier and operation type, and forms a service semantic identifier based on the RDMA semantic content and the tenant identifier. Step S3: The data processor establishes or updates the correspondence between the RDMA connection and the overlay virtual network identifier based on the service semantic identifier. Step S4: The data processor applies superimposed encapsulation or decapsulation processing to the RoCEv2 message according to the corresponding relationship, and adds a semantic extension field reflecting the semantic content of RDMA to the encapsulated message. Step S5: The data processor combines the RDMA semantic content and the acquired network state parameters to perform semantic-driven transmission scheduling operations. Step S6: The data processor implements resource binding and isolation control according to the business semantic identifier and corresponding relationship, and in accordance with the resource configuration strategy issued by the control plane, to complete the construction of the RoCEv2 overlay virtual network.

[0019] Specifically, in this embodiment, the Data Processor (DPU) can be deployed in a host-side smart network interface card, a dedicated network acceleration card, or an integrated data processor. It communicates with the host via the high-speed peripheral interconnect standard PCIe bus and connects to the underlying physical network via an Ethernet port. The control plane system can issue tenant-related network configurations and resource policies to the DPU through a management channel.

[0020] In step S1, the Data Processor (DPU) receives RoCEv2 messages from the host-side transmit path or the network-side receive path, and receives or reads network configuration information associated with the current tenant. The network configuration information may include the tenant identifier (Tenant_ID), overlay virtual network identifier (VNI) allocation rules, the mapping relationship between virtual functions (VF) or virtual ports (vPort) and tenants, scheduling parameters, priority parameters, access control rules, and mapping entry aging parameters, etc. In some implementations, the tenant-related network configuration may be actively issued by the control plane, or it may be read by the Data Processor (DPU) through a local cache table, configuration register, or shared memory.

[0021] In step S2, the data processor (DPU) parses the message to extract RDMA semantic content, including the queue pair identifier (QP_ID) and operation type (Opcode). In a preferred embodiment, the DPU first parses the basic transport header in the message to extract the queue pair identifier (QP_ID) and operation type (Opcode). For messages containing extended transport headers, the remote access key (rkey) field, length field, and memory access-related context information can be further parsed to obtain memory region identifier association information and data length.

[0022] In step S3, the Data Processor (DPU) establishes or updates the mapping relationship between RDMA connections and overlay Virtual Network Identifiers (VNIs) based on the service semantic identifier. In a preferred embodiment, it first queries the existing mapping entries corresponding to the service semantic identifier. If an existing mapping entry is found, the corresponding overlay VNI is directly read and the mapping relationship is reused. If no existing mapping entry is found, the generation or allocation process of the overlay VNI is initiated, and after confirmation, the service semantic identifier and the overlay VNI are recorded in the mapping table. The mapping management module can also maintain an overlay VNI occupancy table, a mapping table from service semantic identifiers to overlay VNIs, and a tenant context table to support fast querying, conflict detection, and state reclamation.

[0023] In this step, the specific timing of the establishment and update is as follows: Mapping establishment timing: When the query result is a no match (i.e. there is no entry in the current mapping table corresponding to the business semantic identifier), it is determined that a new RDMA connection or operation context has appeared for the first time. At this time, the mapping establishment process is triggered to allocate a VNI for the new business semantic identifier and write it into the mapping table.

[0024] Mapping update timing: The mapping update process is triggered under at least one of the following conditions: 1. Policy change trigger: When the control plane actively issues a new resource configuration policy (such as modifying the binding between a tenant and a VNI, adjusting the service level, or access control rules), the DPU updates the binding attribute or policy pointer of the corresponding entry in the mapping table according to the new policy; 2. Semantic information supplementation or correction: When subsequent packets parse more complete semantic information (e.g., expanding from a triple to a quintuple) and need to be associated with different VNIs or policies, the DPU updates the mapping table or points the old identifier to the new identifier; 3. Entry activity status maintenance: Each time an existing mapping entry is successfully matched, the DPU updates the timestamp or activity counter of the entry to prevent it from being incorrectly reclaimed by the aging mechanism.

[0025] In step S4, after determining the mapping relationship, the data processor (DPU) performs overlay encapsulation or decapsulation on the message based on the mapping relationship, and writes a semantic extension field representing the RDMA semantic content into the encapsulation information. In this step, whether to perform overlay encapsulation or decapsulation depends on the message's transmission direction: The timing of the overlay encapsulation process: When the DPU receives the original RoCEv2 message from the host and prepares to send it to the external physical network, overlay encapsulation is performed. Specifically, the DPU obtains the corresponding VNI according to the mapping relationship, constructs the outer tunnel header (such as the VXLAN header), and inserts a semantic extension header after the standard VXLAN header and before the original RoCEv2 message, carrying fields such as QP_ID, Opcode, and Priority. The encapsulated message is then sent to the physical network. This process corresponds to the processing logic of the sending DPU.

[0026] Decapsulation is performed when the DPU receives an overlay-encapsulated packet with a destination address pointing to the local machine from the physical network side. First, the outer tunnel header is parsed to obtain the VNI. Then, the semantic extension header is parsed to extract semantic information such as QP_ID and Opcode. Next, the mapping table is queried based on the VNI and / or semantic information to verify legitimacy and determine the local tenant context. Finally, the outer header and semantic extension header are stripped to restore the original RoCEv2 packet and deliver it to the host side. This process corresponds to the processing logic of the receiving DPU.

[0027] In step S5, the data processor (DPU) performs queue selection, priority control, flow control, or forwarding scheduling based on the RDMA semantic content and network state information.

[0028] In step S6, the data processor (DPU) completes the resource binding and isolation policy execution according to the resource policy issued by the control plane.

[0029] Through the above steps, this embodiment realizes a complete processing chain from message parsing, service semantic identifier generation, mapping establishment, overlay encapsulation, semantic scheduling to resource binding, enabling the construction of an overlay virtual network oriented towards RDMA semantics on the data processor (DPU) side. The core contribution of this solution lies in the fact that it is the first to use core RDMA semantics such as queue pair identifier (QP_ID) and operation type (Opcode) as the primary elements for constructing an overlay virtual network. This refines the granularity of network construction from the traditional tenant or virtual machine level to the RDMA connection level, laying the foundation for subsequent implementation of more refined differentiated services.

[0030] In a preferred embodiment of the present invention, the RDMA semantic content further includes one or more of memory region identifier association information and message data length; the memory region identifier association information is one of the following: a remote access key, or a local access key, or an internal memory region identifier mapped from a remote access key or a local access key; wherein, the internal memory region identifier is obtained by the data processor by reading the access key field in the RoCEv2 message and retrieving the local memory region mapping table.

[0031] Specifically, in this embodiment, the memory region identifier association information may include a remote access key (rkey), a local access key (lkey), or an internal memory region identifier (MR_ID) mapped from them. Specifically, the data processor (DPU) can obtain the internal memory region identifier (MR_ID) by parsing the access key field in the message and querying the local memory region mapping table. The internal memory region identifier (MR_ID) can be allocated or maintained for registered memory regions by the RDMA device driver, hardware context, or the data processor (DPU) internal cache system, and is used for subsequent access permission determination, resource binding, or semantic differentiation.

[0032] By introducing memory region identifier association information and message data length into the semantic content, this embodiment deeply binds message-level parsing with the RDMA memory management mechanism. This enables the Data Processor (DPU) not only to identify which connection is involved and what operation is being performed, but also to further perceive the specific memory region and transmission scale involved in the operation. This information provides the technical possibility for implementing higher-level security strategies (such as memory access permission verification) and more accurate resource prediction (such as pre-allocating buffer resources based on data length).

[0033] In a preferred embodiment of the present invention, the business semantic identifier is composed of a combination of queue pair identifier, tenant identifier and operation type; or, the business semantic identifier is composed of at least one of queue pair identifier, tenant identifier, operation type, memory region identifier association information and data length.

[0034] Specifically, in this embodiment, the tenant identifier (Tenant_ID) can be determined based on the virtual function (VF), virtual port (vPort), virtual machine instance identifier, container namespace identifier, or tenant context pre-issued by the control plane to which the current packet belongs. In one basic construction method, the business semantic identifier can be constructed as a triple consisting of queue pair identifier (QP_ID), tenant identifier (Tenant_ID), and operation type (Opcode), for example, organized in the form of queue pair identifier (QP_ID), tenant identifier (Tenant_ID), and operation type (Opcode). In another more granular construction method, the business semantic identifier can further include at least one of memory region identifier association information and data length, for example, constructed as a quintuple consisting of queue pair identifier (QP_ID), tenant identifier (Tenant_ID), operation type (Opcode), internal memory region identifier (MR_ID), and length.

[0035] This embodiment provides business semantic identifier construction schemes with different granularities, which can flexibly adapt to different application scenarios. The basic scheme using triples can achieve connection-level flow identification while controlling the size of entries and implementation complexity. The extended five-tuple scheme can take into account the specific area of ​​memory access and the scale of transmission, providing direct technical support for scenarios that require differentiated service level protection for specific memory areas (such as giving higher priority to memory areas storing critical data).

[0036] In a preferred embodiment of the present invention, step S3 includes: Check if there is an existing mapping record corresponding to the business semantic identifier. If there is no existing mapping record, allocate a new overlay virtual network identifier based on the business semantic identifier and write the business semantic identifier and the new overlay virtual network identifier into the mapping table.

[0037] Specifically, in this embodiment, one or more mapping tables are maintained internally by the data processor (DPU) to record the correspondence between service semantic identifiers and overlay virtual network identifiers (VNIs). When a packet arrives, the DPU uses the service semantic identifier generated in step S2 as the key to query the mapping table. If a corresponding record is found (i.e., a match is found), the allocated overlay virtual network identifier (VNI) is directly obtained for subsequent encapsulation or scheduling. If no corresponding record is found (i.e., a match is not found), it indicates that this is a new RDMA connection or operation context, and the allocation process is triggered.

[0038] This embodiment, through the aforementioned on-demand query and dynamic creation mechanism, ensures that the overlay Virtual Network Identifier (VNI) resources are only used when actual business occurs, greatly improving the utilization rate of these limited identifier resources. Simultaneously, for already active connections, direct query hits avoid redundant computational overhead, guaranteeing high-speed data plane processing performance.

[0039] In a preferred embodiment of the present invention, such as Figure 2 As shown, step S3 includes: Step S31: The data processor processes the business semantic identifier through a first hash operation to obtain the first candidate identifier; Step S32: When the first candidate identifier has been occupied by other business semantic identifiers, the data processor obtains the second candidate identifier through the second hash operation; Step S33: When the second candidate identifier is still in an occupied state, the data processor performs linear probing based on a preset step size. In step S34, if the data processor still fails to obtain an idle identifier within a preset threshold number of attempts, it sends a request to the control plane to obtain a specified overlay virtual network identifier.

[0040] Specifically, in this embodiment, a multi-level hashing combined with probing mechanism is adopted to achieve efficient and low-collision allocation of overlay virtual network identifiers (VNIs) in the data processor (DPU) hardware. First, a first candidate identifier is obtained by calculating the business semantic identifier (e.g., a semantic key composed of a queue pair identifier QP_ID, a tenant identifier Tenant_ID, and an operation type Opcode) using a first hash function. Then, the occupancy status of the overlay virtual network identifier is checked. If a hash collision occurs, meaning the first candidate identifier VNI is already occupied by another different business semantic identifier, a second hash function (using a different algorithm or seed than the first hash function) is activated to generate a second candidate identifier. If the second candidate identifier still conflicts, a linear probing phase is entered, probing the next position in the identifier space sequentially according to a preset fixed step size. If no usable identifier is found after a preset maximum number of probes (e.g., 3 to 5 times), the data processor (DPU) sends a request to the control plane, which allocates a specified overlay virtual network identifier from the global pool and issues it.

[0041] This embodiment describes a hardware-software co-operational overlay Virtual Network Identifier (VNI) allocation strategy. This strategy cleverly solves the problems of hash collisions and table overload while pursuing line-speed hardware processing. In most cases, an idle VNI can be quickly located through two-level hashing; in extreme collision situations, a control plane fallback ensures the robustness and availability of the system. This mechanism effectively balances the determinism of hardware implementation with the flexibility of control plane management.

[0042] In a preferred embodiment of the present invention, the process of applying superimposed encapsulation processing to the RoCEv2 message in step S4 includes: The RoCEv2 message is encapsulated using the standard VXLAN header, and a semantic extension header is inserted after the standard VXLAN header and before the original RoCEv2 message. The semantic extension header carries the semantic extension fields.

[0043] Specifically, in this embodiment, the data processor (DPU) encapsulates the packet based on the standard VXLAN header. The encapsulated packet sequentially includes an outer Ethernet header, an outer IP header, an outer UDP header, a standard VXLAN header, a semantic extension header, and the original RoCEv2 packet. The semantic extension header is placed after the standard VXLAN header and before the original packet. When the data processor (DPU) is operating in the receive path, it can perform decapsulation processing on the packet according to the mapping relationship and the information in the semantic extension header, and restore the original packet and its corresponding semantic context.

[0044] This embodiment implements a semantic carrying method that is completely transparent to existing network infrastructure by inserting a semantic extension header between the standard VXLAN header and the original RoCEv2 message. Intermediate network switching devices only need to forward the message in the standard VXLAN manner, without any upgrades or modifications, ensuring the solution's plug-and-play capability and broad compatibility. Simultaneously, the semantic coordination between the sending and receiving data processors (DPUs) provides a crucial protocol carrier for building end-to-end deterministic networks based on RDMA semantics.

[0045] In a preferred embodiment of the present invention, the semantic extension field at least covers a queue pair identifier field, an operation type field, and a priority field, wherein the value of the priority field is determined based on at least one of the RDMA semantic content, tenant service level, and network state parameters.

[0046] Specifically, in this embodiment, the semantic extension fields carried in the semantic extension header have clearly defined fields. The queue pair identifier field is used to uniquely identify the current RDMA connection context. The operation type field is used to identify the type of the current RDMA operation, such as SEND, WRITE, READ, etc. The priority field is used to characterize the priority of the current packet in subsequent network transmission and internal processing by the data processor (DPU). The value of this priority field can be dynamically determined by combining multiple factors: it can be based on the characteristics of the operation type Opcode itself (e.g., setting high priority for control operations), or it can be combined with the level in the tenant's Service Level Agreement (SLA), or it can refer to the current network congestion status.

[0047] By explicitly defining the queue pair identifier field, operation type field, and priority field, this embodiment embeds crucial RDMA semantic information into the extended header of the message. In particular, the dynamically configurable priority field allows downstream network devices or peer data processors (DPUs) to obtain the priority without repeatedly parsing the original RoCEv2 message, achieving end-to-end priority inheritance and providing precise identification information for building a differentiated quality of service assurance system based on connection and operation granularity.

[0048] In a preferred embodiment of the present invention, step S5 includes: generating a scheduling evaluation value based on explicit congestion notice, round-trip time, queue depth and operation weight factor corresponding to the operation type, and determining the target queue, priority parameter or rate limit parameter based on the scheduling evaluation value.

[0049] Specifically, in this embodiment, the Data Processor (DPU) continuously collects network status information from local ports or internal queues, including the proportion of Explicit Congestion Notice (ECN) markers, round-trip time (RTT) measurements, and queue depth (QueueDepth) for each queue. Simultaneously, the DPU internally pre-configures or receives an operation weight mapping table from the control plane, configuring corresponding operation weight factors (OpcodeWeight) for different operation types (Opcode). For example, RDMA control operations or atomic operations that are highly sensitive to latency can be assigned a larger weight factor. Based on these inputs, the DPU calculates a comprehensive scheduling evaluation value. This evaluation value can be a linear weighted sum, for example, ,in, This is a preset adjustable weighting coefficient. Based on the calculated scheduling evaluation value C, the data processor (DPU) executes corresponding scheduling actions: sending packets with high C values ​​to the high-priority queue; and rate-limiting or sending packets with low C values ​​to the low-priority queue.

[0050] This embodiment jointly models operational semantics (represented by the operation weight factor OpcodeWeight) with real-time network conditions (Explicit Congestion Notice (ECN), Round Trip Time (RTT), and Queue Depth) to generate a scheduling evaluation value. This algorithm makes scheduling decisions no longer rigid and based on a single factor, but intelligently balances the importance of operations with the immediate level of network congestion. For example, under mild network congestion, it can provide low-latency services for more operations; while under severe network congestion, it prioritizes the transmission of high-weight operations (such as control operations) and actively restricts low-weight operations (such as batch writes), thereby maximizing the overall system utility under complex load scenarios.

[0051] In a preferred embodiment of the present invention, the resource configuration strategy in step S6 includes at least one of the following: a tenant-overlay virtual network identifier binding strategy, an RDMA connection-queue resource binding strategy, a memory region access control strategy, a priority strategy, and a mapping entry aging strategy; the RoCEv2 overlay virtual network construction method further includes: releasing the corresponding mapping entry and overlay virtual network identifier when it is detected that the RDMA connection is closed, the mapping entry meets the preset idle condition, or the virtual network instance is revoked.

[0052] Specifically, in this embodiment, the Data Processor (DPU) enforces fine-grained resource binding and isolation on the data plane based on various resource policies issued by the control plane. Specifically, it binds the Tenant ID (Tenant_ID) to the set of allowed Overlay Virtual Network Identifiers (VNIs); binds the Queue Pair Identifier (QP_ID) to a specific hardware transmission queue; and performs memory region access control based on internal memory region identifiers such as MR_ID. Furthermore, to maintain the long-term stability of the system, when the DPU detects that the RDMA connection is closed, the mapping entry has no packet activity within a preset time threshold, or it receives a revocation command from the control plane, it will proactively release the mapping entry and mark the corresponding Overlay Virtual Network Identifier (VNI) as idle.

[0053] This embodiment constructs a complete closed-loop management mechanism from resource binding and policy execution to state reclamation. By associating and constraining resources across multiple dimensions such as tenants, connections, queues, and memory regions, the Data Processor (DPU) transforms from a relatively passive forwarding unit into an active infrastructure processing node with resource management capabilities. In particular, the automated aging and reclamation mechanism ensures that scarce resources such as overlay Virtual Network Identifiers (VNIs) and entry spaces are not exhausted due to connection anomalies or prolonged idle periods. This is crucial for ensuring the long-term stability and maintainability of the system in a multi-tenant environment.

[0054] In a preferred embodiment of the present invention, a data processor is also provided, which applies the above-described RoCEv2 overlay virtual network construction method, such as... Figure 3 As shown, it includes: The message parsing module 1 is used to receive RoCEv2 messages and obtain the network configuration related to the tenant, as well as to perform parsing on the RoCEv2 messages; Semantic identifier generation module 2 is connected to message parsing module 1 and is used to extract RDMA semantic content containing queue pair identifiers and operation types from the parsing results, and generate service semantic identifiers in conjunction with tenant identifiers; The mapping management module 3 and the connection semantic identifier generation module 2 are used to establish or update the correspondence between RDMA connection and overlay virtual network identifier based on the business semantic identifier; The overlay processing module 4 is connected to the mapping management module 3, and is used to perform overlay encapsulation or decapsulation on RoCEv2 messages according to the corresponding relationship, and add semantic extension fields reflecting RDMA semantic content to the encapsulated messages. The scheduling control module 5 is connected to the semantic identifier generation module 2 and is used to perform semantic-driven transmission scheduling operations based on RDMA semantic content and network status parameters. The resource policy execution module 6 connects the mapping management module 3 and the overlay processing module 4. It is used to implement resource binding and isolation control based on the resource configuration policy issued by the control plane according to the business semantic identifier and the corresponding relationship, so as to realize the construction of RoCEv2 overlay virtual network.

[0055] Specifically, in this embodiment: the message parsing module 1 is configured to receive raw RoCEv2 messages and obtain network configuration information related to the current tenant (such as tenant identifier Tenant_ID, VPC configuration, etc.) from the DPU control plane. This module uses deep message parsing technology to disassemble the basic and extended transport headers of the RoCEv2 message, extracting in real time core fields including but not limited to queue pair identifier QP_ID, opcode, access key field (rkey / lkey), and message payload length, providing basic data support for subsequent semantic recognition.

[0056] Semantic identifier generation module 2 is connected to message parsing module 1 and is used to jointly encode the extracted QP_ID, Opcode, and Tenant identifier (Tenant_ID) to generate a globally unique service semantic identifier. In a preferred embodiment, this module is also configured to query the local memory region mapping table based on the parsed access key field to obtain the internal memory region identifier (MR_ID) and data length information, and integrate them into the service semantic identifier, thereby achieving precise characterization of RDMA communication granularity from stream to connection and even memory access tasks.

[0057] The core logic of the mapping management module 3 lies in establishing a dynamic association between business semantic identifiers and overlaid virtual network identifiers (such as VXLANVNI). This module maintains a high-performance mapping table. When the semantic identifier generation module 2 sends in a new identifier, it first queries existing entries. If no match is found, an automatic allocation mechanism is initiated. Mapping generation strategy: Supports generating VNIs based on hash algorithms (such as CRC32 or consistent hashing), or requesting the allocation of specific VNIs through the control plane interface.

[0058] Conflict handling: During the hash generation process, this module uses a multi-level hashing mechanism (first hash, second hash) combined with a linear probing algorithm to resolve entry conflicts, ensuring the efficiency and accuracy of mapping relationships in a large-scale multi-tenant environment.

[0059] The overlay processing module 4 is responsible for the specific tunnel encapsulation and decapsulation operations. Its key innovation lies in: Encapsulation structure: When performing encapsulation of standard tunneling protocols (such as VXLAN, GENEVE), this module inserts a custom semantic extension header between the standard tunnel header (such as the VXLAN header) and the original RoCEv2 message.

[0060] Field Definitions: The semantic extension header must contain at least the QP_ID, Opcode, and a preset Priority field that reflect the RDMA semantics. This structure allows intermediate network nodes or peer receiving devices to directly identify the semantic characteristics of the RoCEv2 service without deeply analyzing the inner tunnel packets.

[0061] The scheduling control module 5 implements fine-grained scheduling using semantic extension fields and network feedback. This module combines real-time parameters such as explicit congestion notification (ECN), round-trip time (RTT), and switch queue depth (QueueDepth), and refers to the weighting factor (OpcodeWeight) of different operation types (Opcodes) to perform queue selection, dynamic grading, and rate limiting control on RoCEv2 traffic. For example, specific scheduling priorities are assigned to large-block data transfers such as RDMA WRITE / READ to ensure the throughput requirements of high-performance computing or distributed storage services.

[0062] Resource policy execution module 6, as the underlying support unit, is primarily responsible for: Resource isolation: Based on the configuration issued by the control plane, business semantic identifiers are forcibly bound to specific physical / virtual resources (such as specific memory pools and hardened queue resources) to achieve strict isolation of multi-tenants at the hardware level.

[0063] Dynamic aging and reclamation: An internally integrated automated resource reclamation mechanism monitors the activity of each mapping record in real time. For business semantic entries that have been idle for a long time or have detected connection anomalies, the VNI and table space they occupy are automatically reclaimed to prevent scarce resources from being exhausted due to long-term connection remnants.

[0064] Further, refer to Figure 3 This embodiment also details the location and interaction relationships of the device within the overall network architecture: The Data Processor (DPU), as the hardware carrier of this device, is deployed between the server host and the external network environment, serving as the core processing hub between the host-side RDMA services and the virtualized network. On the one hand, it directly interacts with the host-side RDMA driver and memory area through an internal bus (such as PCIe) to obtain the raw RoCEv2 service flow; on the other hand, using the aforementioned packet parsing, semantic identifier generation, and overlay processing modules, it completes the conversion from raw RDMA semantics to virtual network encapsulation at hardware line speed, realizing hardware offloading and virtualization enhancement of the high-performance network protocol stack.

[0065] The underlying physical network connects the data processor (DPU) and the peer node, providing Layer 3 (UDP / IP) transport and routing forwarding for the encapsulated RoCEv2 packets. In this embodiment, the encapsulated packets with semantic extension headers output by the overlay processing module 4 enter the underlying physical network through the physical port of the DPU. Since the header of the encapsulated packet directly maps the semantic characteristics of RDMA (such as operation type priority, queue identifier, etc.), the switching devices in the underlying physical network (such as switches supporting lossless Ethernet features such as ECN and PFC) can identify the service attributes of the traffic without deep packet disassembly, thereby executing fine-grained congestion control and traffic engineering strategies to ensure that RDMA services can still maintain extremely low latency and zero packet loss characteristics in the physical network after being encapsulated through a virtualized tunnel.

[0066] The peer node, acting as the remote target for RDMA communication, achieves direct cross-node memory access with the Data Processor (DPU) through the underlying physical network. In this embodiment, a logical semantic-aware tunnel is constructed between the DPU and the peer node based on service semantic identifiers. During the transmission process, the DPU transforms the local host's memory access request into a tunnel message that meets tenant isolation requirements. During the reception process, when the peer node (which typically also has a DPU or smart NIC with similar functionality deployed internally) receives this message, it can quickly recover the original RDMA semantic context based on the tunnel header and semantic extension fields, and perform precise resource matching and data writing in conjunction with the mapping relationship. This end-to-end cooperation mechanism ensures that RoCEv2 services can still achieve strict security isolation and deterministic performance guarantees among multiple tenants in complex overlay virtual network environments.

[0067] This embodiment provides a hardware implementation scheme corresponding one-to-one with the aforementioned methods, modularly integrating core functions such as RDMA semantic awareness, dynamic mapping, extended encapsulation, semantic-driven scheduling, and resource closed-loop management within the data processor (DPU). This modular design facilitates hardware implementation and functional verification. The modules work collaboratively to achieve a leap in capability from traditional indiscriminate forwarding to intelligent overlay network construction that is aware of RDMA semantics.

[0068] In a preferred embodiment of the present invention, an electronic device is also provided, including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the foregoing method embodiments.

[0069] Electronic devices can be data processing devices with integrated data processors (DPUs), smart network interface cards (NICs), network acceleration devices, or network node devices with programmable data plane processing capabilities.

[0070] In a preferred embodiment of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of any of the foregoing method embodiments.

[0071] Computer-readable storage media can be non-transitory storage media, including but not limited to read-only memory (ROM), random access memory (RAM), flash memory, solid-state drive (SSD), disk, or other storage media capable of storing program code.

[0072] The above are merely preferred embodiments of the present invention and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should recognize that any equivalent substitutions and obvious changes made using the content of this specification and illustrations should be included within the protection scope of the present invention.

Claims

1. A RoCEv2 overlay virtual network construction method, applied to a data processor, characterized in that, include: Step S1: The data processor receives the RoCEv2 message and obtains the network configuration information associated with the current tenant; Step S2: The data processor parses the RoCEv2 message, extracts RDMA semantic content including queue pair identifier and operation type, and forms a service semantic identifier based on the RDMA semantic content and the tenant identifier. Step S3: The data processor establishes or updates the correspondence between the RDMA connection and the overlay virtual network identifier based on the service semantic identifier; Step S4: The data processor applies superimposed encapsulation processing or decapsulation processing to the RoCEv2 message according to the correspondence, and adds a semantic extension field reflecting the semantic content of the RDMA to the encapsulated message; Step S5: The data processor combines the RDMA semantic content and the acquired network state parameters to perform semantic-driven transmission scheduling operations. Step S6: The data processor, based on the service semantic identifier and the corresponding relationship, implements resource binding and isolation control according to the resource configuration strategy issued by the control plane to complete the construction of the RoCEv2 overlay virtual network.

2. The RoCEv2 overlay virtual network construction method according to claim 1, characterized in that, The RDMA semantic content also includes one or more of the memory region identifier association information and message data length; The memory region identifier associated information is one of the following: a remote access key, a local access key, or an internal memory region identifier mapped from a remote access key or a local access key; The internal memory region identifier is obtained by the data processor by reading the access key field in the RoCEv2 message and retrieving the local memory region mapping table.

3. The RoCEv2 overlay virtual network construction method according to claim 2, characterized in that, The business semantic identifier is composed of the queue pair identifier, the tenant identifier, and the operation type; Alternatively, the business semantic identifier may be composed of at least one of the following: queue pair identifier, tenant identifier, operation type, memory region identifier association information, and data length.

4. The RoCEv2 overlay virtual network construction method according to claim 3, characterized in that, Step S3 includes: The data processor checks whether there is an existing mapping record corresponding to the business semantic identifier. If there is no existing mapping record, it allocates a new overlay virtual network identifier based on the business semantic identifier and writes the business semantic identifier and the new overlay virtual network identifier into the mapping table.

5. The RoCEv2 overlay virtual network construction method according to claim 4, characterized in that, Step S3 includes: Step S31: The data processor processes the business semantic identifier through a first hash operation to obtain a first candidate identifier; Step S32: When the first candidate identifier has been occupied by other business semantic identifiers, the data processor obtains the second candidate identifier through a second hash operation; Step S33: When the second candidate identifier is still in an occupied state, the data processor performs linear probing based on a preset step size; In step S34, if the data processor still fails to obtain an idle identifier within a preset threshold number of attempts, it sends a request to the control plane to obtain the specified overlay virtual network identifier.

6. The RoCEv2 overlay virtual network construction method according to claim 1, characterized in that, The process of applying superimposed encapsulation to the RoCEv2 message in step S4 includes: The data processor encapsulates the RoCEv2 message using a standard VXLAN header and inserts a semantic extension header after the standard VXLAN header and before the original RoCEv2 message, using the semantic extension header to carry the semantic extension fields.

7. The RoCEv2 overlay virtual network construction method according to claim 6, characterized in that, The semantic extension field at least covers a queue pair identifier field, an operation type field, and a priority field, wherein the value of the priority field is determined based on at least one of the RDMA semantic content, tenant service level, and network state parameters.

8. The RoCEv2 overlay virtual network construction method according to claim 1, characterized in that, Step S5 includes: The data processor generates a scheduling evaluation value based on explicit congestion notices, round-trip delays, queue depth, and operation weight factors corresponding to the operation type, and determines the target queue, priority parameters, or rate limit parameters based on the scheduling evaluation value.

9. The RoCEv2 overlay virtual network construction method according to claim 1, characterized in that, The resource allocation strategy in step S6 includes: At least one of the following: a tenant-overlay virtual network identifier binding strategy, an RDMA connection-queue resource binding strategy, a memory region access control strategy, a priority strategy, and a mapping entry aging strategy; The RoCEv2 overlay virtual network construction method further includes: releasing the corresponding mapping entry and overlay virtual network identifier when it is detected that the RDMA connection is closed, the mapping entry meets the preset idle condition, or the virtual network instance is revoked.

10. A data processor, characterized in that, The RoCEv2 overlay virtual network construction method described in claims 1-9 includes: The message parsing module is used to receive RoCEv2 messages and obtain network configurations related to tenants, as well as to perform parsing on RoCEv2 messages; The semantic identifier generation module, connected to the message parsing module, is used to extract RDMA semantic content containing queue pair identifiers and operation types from the parsing results, and generate business semantic identifiers in conjunction with tenant identifiers. The mapping management module connects to the semantic identifier generation module and is used to establish or update the correspondence between RDMA connections and overlay virtual network identifiers based on business semantic identifiers. The overlay processing module is connected to the mapping management module and is used to perform overlay encapsulation or decapsulation on RoCEv2 messages according to the corresponding relationship, and add semantic extension fields reflecting RDMA semantic content to the encapsulated messages. The scheduling control module is connected to the semantic identifier generation module and is used to perform semantic-driven transmission scheduling operations based on RDMA semantic content and network status parameters. The resource policy execution module connects the mapping management module and the overlay processing module. It is used to implement resource binding and isolation control based on the resource configuration policy issued by the control plane according to the business semantic identifier and the corresponding relationship, so as to realize the construction of RoCEv2 overlay virtual network.

Images