Traffic prediction method, device, equipment, medium and program product

Abstract

The application provides a traffic prediction method and device, equipment, medium and program product, relates to the communication technical field, and is used for guaranteeing the transmission efficiency of data. The specific technical scheme is as follows: in the case that an RDMA work request is received, based on a QP handle of a QP associated with the RDMA work request, a destination address and an MTU in a transmission path corresponding to the QP handle are acquired, the RDMA work request is used for requesting transmission of first data through an RDMA communication link, and the RDMA work request includes a data segment length of the first data and a transmission operation type; based on the data segment length and the MTU, first traffic information corresponding to the first data is determined; based on the transmission operation type and the destination address, second traffic information corresponding to the first data is determined; and based on the first traffic information and the second traffic information, target traffic information is predicted. The application is applied to an RDMA data center network service scene.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a traffic prediction method, apparatus, device, medium, and program product. Background Technology

[0002] In related technologies, for data center network traffic perception and scheduling optimization, network load information, i.e. data transmission traffic information, is mainly obtained by means of traffic detection, counter statistics or active probing.

[0003] Typically, in RDMA scenarios, related technologies will statistically analyze or detect the traffic that has already occurred. For example, they can identify large flows through end hosts or switches, or summarize and analyze based on historical traffic counters to obtain data transmission traffic information.

[0004] However, the feedback of data transmission traffic information is relatively delayed, which makes it impossible to accurately allocate and schedule the corresponding network resources for data transmission, and thus cannot guarantee the efficiency of data transmission. Summary of the Invention

[0005] This application provides a traffic prediction method, apparatus, device, medium, and program product to ensure data transmission efficiency.

[0006] In a first aspect, embodiments of this application provide a traffic prediction method, the method comprising: upon receiving an RDMA work request, obtaining, based on the QP handle of a QP associated with the RDMA work request, a destination address and a transmission path MTU corresponding to the QP handle, wherein the RDMA work request is used to request the transmission of first data through an RDMA communication link, and the RDMA work request includes a data segment length and a transmission operation type of the first data; determining, based on the data segment length and the MTU, first traffic information corresponding to the first data; determining, based on the transmission operation type and the destination address, second traffic information corresponding to the first data; and predicting, based on the first traffic information and the second traffic information, target traffic information, wherein the target traffic information is the traffic information when the first data is transmitted through the RDMA communication link.

[0007] The technical solution provided in this application brings at least the following beneficial effects: In this solution, the traffic prediction process can be directly triggered when the RDMA working request is received, so that traffic calculation for data transmission can be realized before the data enters the network, and the corresponding network resources can be allocated and scheduled for the data transmission process based on the traffic prediction calculation results, thereby ensuring the efficiency of data transmission.

[0008] One possible implementation, wherein determining the first traffic information corresponding to the first data based on the data segment length and the MTU, includes: calculating the total data length of the first data based on the data segment length; generating at least one data packet corresponding to the first data based on the total data length and the MTU; and calculating the first traffic information corresponding to the first data based on the basic header length corresponding to each data packet.

[0009] Another possible implementation, in which the second traffic information corresponding to the first data is determined based on the transmission operation type and the destination address, includes: determining the destination and source of the first data transmission based on the destination address; calculating the third traffic information from the source to the destination and the fourth traffic information from the destination to the source of the first data based on the destination and source of the first data transmission and the transmission operation type; and determining the second traffic information corresponding to the first data based on the third traffic information and the fourth traffic information.

[0010] Another possible implementation is that the above transmission operation type includes any of the following: send operation, RDMA write operation, and RDMA read operation.

[0011] Another possible implementation involves obtaining the destination address and MTU in the transmission path corresponding to the QP handle associated with the aforementioned RDMA work request. This includes: if a query result corresponding to the aforementioned QP is found in the local cache, obtaining the QP context information corresponding to the aforementioned QP handle; or, if a query result corresponding to the aforementioned QP is not found in the local cache, calling the first interface to query the QP context information in the Remote Direct Memory Access Network Interface (RNIC); wherein the aforementioned QP context information includes the aforementioned destination address and the aforementioned MTU.

[0012] Secondly, embodiments of this application provide a traffic prediction apparatus, comprising: an acquisition module, a processing module, and a prediction module; the acquisition module is configured to, upon receiving an RDMA work request, acquire, based on the QP handle of the QP associated with the RDMA work request, the destination address and the MTU in the transmission path corresponding to the QP handle, wherein the RDMA work request is used to request the transmission of first data through an RDMA communication link, and the RDMA work request includes the data segment length and transmission operation type of the first data; the processing module is configured to determine first traffic information corresponding to the first data based on the data segment length and the MTU; the processing module is further configured to determine second traffic information corresponding to the first data based on the transmission operation type and the destination address; the prediction module is configured to predict target traffic information based on the first traffic information and the second traffic information, wherein the target traffic information is the traffic information when the first data is transmitted through the RDMA communication link.

[0013] One possible implementation is that the above processing module is specifically used to: calculate the total data length of the first data based on the data segment length; generate at least one data packet corresponding to the first data based on the total data length and the MTU; and calculate the first traffic information corresponding to the first data according to the basic header length corresponding to each data packet.

[0014] Another possible implementation, the above processing module is specifically used to: determine the destination and source of the first data transmission based on the destination address; calculate the third flow information of the first data from the source to the destination and the fourth flow information of the first data from the destination to the source based on the destination and source of the first data transmission and the transmission operation type; and determine the second flow information corresponding to the first data based on the third flow information and the fourth flow information.

[0015] Another possible implementation is that the above transmission operation type includes any of the following: send operation, RDMA write operation, and RDMA read operation.

[0016] Another possible implementation is that the above-mentioned acquisition module is specifically used to: if the query result corresponding to the above-mentioned QP is retrieved in the local cache, obtain the QP context information corresponding to the above-mentioned QP handle; or, if the query result corresponding to the above-mentioned QP is not retrieved in the local cache, call the first interface to query the QP context information in the remote direct memory access network card RNIC; wherein the above-mentioned QP context information includes the above-mentioned destination address and the above-mentioned MTU.

[0017] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory stores a program or instructions executable on the processor, wherein the program or instructions, when executed by the processor, implement the method of the first aspect described above.

[0018] Fourthly, this application provides a readable storage medium on which a program or instructions are stored, which, when executed by a computer, implement the method of the first aspect described above.

[0019] Fifthly, this application provides a computer program product stored in a storage medium, which, when executed by a computer, implements the method described in the first aspect.

[0020] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the method described in the first aspect.

[0021] The beneficial effects of the second to sixth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description

[0022] Figure 1 A schematic diagram of a network architecture for applying a traffic prediction method according to an embodiment of this application;

[0023] Figure 2 A flowchart illustrating a traffic prediction method provided in an embodiment of this application;

[0024] Figure 3 A flowchart illustrating another traffic prediction method provided in an embodiment of this application;

[0025] Figure 4 A flowchart illustrating another traffic prediction method provided in an embodiment of this application;

[0026] Figure 5 A flowchart illustrating another traffic prediction method provided in an embodiment of this application;

[0027] Figure 6 This is a schematic diagram of the structure of a flow prediction device provided in an embodiment of this application;

[0028] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0030] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0031] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0032] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0033] The traffic prediction method, apparatus, device, medium, and program products provided in this application can be applied to RDMA data center network service scenarios. Examples include: RDMA high-speed cluster network scheduling scenarios for large-scale Artificial Intelligence (AI) model training; remote transaction interaction scenarios for RDMA databases (in-memory databases / distributed databases); topology reconstruction scenarios for high-performance computing RDMA parallel computing clusters; and RDMA bare-metal elastic tenant network isolation and bandwidth reservation scenarios in cloud data centers.

[0034] In related technologies, network load information for data center network traffic awareness and scheduling optimization is mainly obtained through methods such as traffic detection, counter statistics, or active probing. Specifically, the following three solutions can be listed:

[0035] Option 1: Mahout Host High-Flow Detection and Control Solution

[0036] Mahout is an early and representative host-side traffic visualization and control solution. Its core idea is not to monitor all flows per flow within the switch, but rather to add a shim layer to the end host's operating system to detect existing traffic. Once an elephant flow is detected, the end host notifies the central controller via in-band signaling, allowing the controller to further manage the elephant flow. Publicly available information shows that Mahout explicitly proposes detecting elephant flows at the end host through the shim layer and notifying the controller via an in-band mechanism, thus avoiding the high overhead of flow-by-flow monitoring by the switch.

[0037] Option 2: XFabric's demand matrix construction scheme based on periodic counter reporting

[0038] XFabric is a demand estimation and topology reconfiguration solution for reconfigurable data center networks. Its controller periodically collects traffic demand information from each System-on-Chips (SoC) / node, aggregates it into a demand matrix, and optimizes the rack topology accordingly. Publicly available information shows that each SoC in XFabric maintains a vector recording the number of bytes it sends to other SoCs; for external traffic, it also maintains send and receive byte counts. Nodes periodically report these demand vectors to the controller, which then aggregates them into an n×n demand matrix and calculates the new network configuration based on it.

[0039] Option 3: Hostmesh / Ethernet Remote Direct Memory Access (RDMA over Converged Ethernet, RoCE) Active Probing Network Monitoring and Diagnostic Solution

[0040] Hostmesh is a network monitoring and diagnostic solution for rail-optimized RoCE clusters. Its core method involves active full-mesh probing between multiple RDMA Network Interface Cards (RNICs) on the same host. By modifying the five-tuple of the probing packets to cover different paths, it measures one-way network latency, end-host processing latency, and detects one-way packet loss. Publicly available information indicates that Hostmesh explicitly positions itself as an active probing monitoring and diagnostic system for RoCE clusters, relying on full-mesh probing between host RNICs and submitting the measurement results to an analyzer for Service Level Agreement (SLA) tracing and fault location.

[0041] However, the above solution still has the following shortcomings in RDMA network scenarios:

[0042] (1) Related technologies generally rely on the statistics or detection of traffic that has already occurred, such as identifying large flows through end hosts or switches, or summarizing and analyzing based on historical traffic counters. The traffic information obtained by these methods has obvious lag and cannot provide the corresponding traffic scale information before the communication request enters the network, thus making it difficult to support front-end network scheduling and resource allocation.

[0043] (2) Related technologies typically aggregate traffic based on time windows or statistical periods, resulting in coarse-grained information that is difficult to accurately reflect the traffic characteristics of a single communication request. In RDMA scenarios, different work requests differ significantly in data size, operation type, and communication direction, making it difficult for periodic statistical methods to accurately characterize a single request.

[0044] (3) Related technologies lack the ability to perform refined modeling of RDMA communication semantics. Under the RDMA mechanism, the three operations of sending, writing, and reading differ in terms of data flow, protocol overhead, and acknowledgment mechanism. However, existing methods usually do not combine the work request structure information with the queue pair (QP) context information for joint analysis, and cannot accurately calculate the bidirectional traffic scale under different operation types.

[0045] (4) Although related technologies can construct network traffic matrices or global views to a certain extent, they are mostly derived based on historical statistics or detection results. They cannot directly generate future traffic prediction results when communication requests are submitted, so they are difficult to meet the network optimization scenarios with high requirements for real-time performance and foresight.

[0046] To address the aforementioned technical problems, this application provides a traffic prediction method, apparatus, device, medium, and program product. Upon receiving an RDMA work request, based on the QP handle associated with the RDMA work request, the method obtains the destination address and MTU in the transmission path corresponding to the QP handle. The RDMA work request requests the transmission of first data via an RDMA communication link, and includes the data segment length and transmission operation type of the first data. Based on the data segment length and the MTU, first traffic information corresponding to the first data is determined. Based on the transmission operation type and the destination address, second traffic information corresponding to the first data is determined. Based on the first and second traffic information, target traffic information is predicted, which is the traffic information during the transmission of the first data via the RDMA communication link. In this solution, the traffic prediction process can be directly triggered upon receiving the RDMA work request, enabling traffic calculation before data enters the network. Based on the predicted traffic calculation results, corresponding network resources are allocated and scheduled for the data transmission process, thereby ensuring data transmission efficiency.

[0047] The following description, in conjunction with the accompanying drawings, details the flow prediction method, apparatus, device, medium, and program products provided in the embodiments of this application.

[0048] Figure 1 The diagram illustrates a network architecture for applying a traffic prediction method according to an embodiment of this application. For example... Figure 1 As shown, the network architecture includes a traffic prediction device 101 and a terminal device 102. The traffic prediction device 101 and the terminal device 102 are interconnected.

[0049] In some embodiments, the traffic prediction device 101 may be a server, a computer, or a processor or processing unit within a server or computer. The server may be a single server or a server cluster consisting of multiple servers. It should be noted that the embodiments of this application do not limit the specific device form of the traffic prediction device 101. Figure 1 The example shown is a traffic prediction device 101, which is a single server.

[0050] In some embodiments, the terminal device may be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc., and the embodiments of this application do not specifically limit it. Figure 1 The example shown is a mobile phone, with terminal device 102 as an example.

[0051] In some embodiments, upon receiving an RDMA work request, the traffic prediction device 101 obtains the destination address and MTU in the transmission path corresponding to the QP handle associated with the RDMA work request, whereby the RDMA work request requests the transmission of first data via an RDMA communication link. The RDMA work request includes the data segment length and transmission operation type of the first data. Based on the data segment length and the MTU, it determines first traffic information corresponding to the first data. Based on the transmission operation type and the destination address, it determines second traffic information corresponding to the first data. Based on the first and second traffic information, it predicts target traffic information, which is the traffic information when the first data is transmitted via the RDMA communication link. The traffic prediction device 101 allocates and schedules corresponding network resources for the service corresponding to the RDMA work request based on the target traffic information, and the terminal device 102 executes the corresponding service based on the allocated and scheduled network resources.

[0052] It should be noted that the network architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As network architectures evolve, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0053] See Figure 2 This is a flowchart illustrating a traffic prediction method provided in an embodiment of this application. Figure 2 As shown, the traffic prediction method provided in this application embodiment can be implemented by the above-mentioned traffic prediction device, specifically including the following steps 201 to 204.

[0054] Step 201: When the traffic prediction device receives an RDMA working request, it obtains the destination address and MTU in the transmission path corresponding to the QP handle based on the QP handle associated with the RDMA working request.

[0055] In some embodiments, the RDMA work request described above is used to request the transmission of first data through an RDMA communication link.

[0056] In some embodiments, the RDMA work request includes the data segment length of the first data and the transmission operation type.

[0057] In some embodiments, the aforementioned RDMA work request originates from an application.

[0058] For example, when the traffic prediction device receives an RDMA work request from an application, the traffic prediction process is triggered immediately, which is the technical solution provided in this application. Specifically, when the application calls ibv_post_send to submit an RDMA work request to a specified QP, the prediction traffic broker embedded in the Verbs framework is activated by an event.

[0059] It should be noted that the aforementioned RDMA work request may also include a hash table of the first data and related control parameters.

[0060] In some embodiments, the first data mentioned above is data to be transmitted, which may be data to be sent or data to be received.

[0061] In some embodiments, combined with Figure 2 ,like Figure 3 As shown, step 201 above can be implemented through step 201a or step 201b below.

[0062] Step 201a: If the query result corresponding to QP is retrieved in the local cache, the traffic prediction device obtains the QP context information corresponding to the QP handle.

[0063] Step 201b: If no query result corresponding to QP is found in the local cache, the traffic prediction device calls the first interface to query the QP context information in the RNIC.

[0064] In some embodiments, the QP context information described above includes the destination address and the maximum transmission unit (MTU) in the transmission path.

[0065] In some embodiments, the destination address is the destination address for transmitting the first data.

[0066] For example, the destination address mentioned above can be represented by the destination end.

[0067] In some embodiments, the MTU described above is used to characterize the maximum transmission granularity of a message.

[0068] For example, the aforementioned destination address and MTU are recorded in the Queue PairContext (QPC) information of the RNIC, which can be obtained by querying ibv_query_qp. The query result is returned to the qp_attr attribute structure, where the member dgid represents the destination address and the member path_mtu represents the MTU of the transmission path corresponding to the QP.

[0069] For example, the traffic prediction device, based on the QP handle associated with the RDMA work request, first determines whether the query result for that QP already exists in the local host cache. If it exists, the destination address and MTU are read directly from the cache; if not, ibv_query_qp is called to query the QP context in the RNIC, and the returned dgid and path_mtu are written into the cache. Subsequent requests sent by the same QP can directly hit the cache. The reason for setting up this cache is that directly calling ibv_query_qp has a large overhead, typically reaching tens of microseconds, while caching can significantly reduce read latency.

[0070] For example, the above caching method can use the QP number as the index, and each cache table entry contains at least three types of information: QP number, destination network address, and MTU.

[0071] In this way, through the above process, the two parts of information, "how much data to be sent this time" and "where this data is to be sent and at what message granularity," can be pieced together to create conditions for accurately calculating the number of future messages.

[0072] Step 202: The flow prediction device determines the first flow information corresponding to the first data based on the data segment length of the first data and the MTU corresponding to the first data.

[0073] In some embodiments, the traffic prediction device calculates the total length of the first data based on the data segment length of the first data, then divides it according to the MTU to obtain at least one data packet, and then determines the first traffic information based on the base header length of these data packets.

[0074] In some embodiments, the aforementioned first traffic information is the basic traffic information required to transmit all the first data.

[0075] In some embodiments, combined with Figure 2 ,like Figure 4As shown, step 202 above can be specifically implemented through steps 202a to 202c below.

[0076] Step 202a: The flow prediction device calculates the total length of the first data based on the data segment length.

[0077] In some embodiments, the total length of the data is the total amount of data in the first data, or the total number of data bytes.

[0078] For example, the first step is to determine the total amount of data actually involved in this work request. Although the sg_list in the work request may contain multiple discrete data segments, i.e., the first data mentioned above, in the RDMA protocol, these data from different segments can be continuously encapsulated and mapped into a set of messages to be transmitted. Therefore, the calculation of the number of messages is not based on the "number of segments," but on the "sum of the lengths of all segments," that is, adding the lengths of each data segment in the first data to obtain the total length of the first data, i.e., the total amount of data mentioned above. This total length can be denoted as DL.

[0079] For example, if the current RDMA work request contains three scattered data segments with lengths L1, L2 and L3 respectively, then the total data length of the first data segment is DL = L1 + L2 + L3.

[0080] It should be noted that the calculation here is for the number of bytes of the original business data to be carried, excluding any network headers and control information. These protocol overheads will be further added in subsequent steps.

[0081] Step 202b: The flow prediction device generates at least one data packet corresponding to the first data based on the total data length and MTU.

[0082] In some embodiments, the traffic prediction device divides the first data into at least one data packet according to the MTU corresponding to the first data, wherein the length or number of bytes of each data packet is less than or equal to the MTU.

[0083] For example, the traffic prediction device can use formula (1) to calculate the number of data packets N, where N is a positive integer.

[0084] For example, formula (1) is shown below:

[0085] N = ceil(DL / MTU) (1)

[0086] Where N is the number of data packets that the first data is divided into, DL is the total length of the first data, and ceil is the round-up function.

[0087] It is understandable that when the total length of the first data is not divisible by the MTU, an additional message is still needed to carry the remaining data, so the integer value is taken.

[0088] For example, when DL=4096 bytes and MTU=1024 bytes, the data will be divided into N=4 packets; if DL=4100 bytes, then N=5 packets are still required. In other words, even a very small number of extra bytes will trigger a complete packet and its basic header overhead.

[0089] Step 202c: The flow prediction device calculates the first flow information corresponding to the first data based on the basic header length of each data packet.

[0090] In some embodiments, the above-mentioned base header is the base protocol header, and the length of the base header can be the base protocol header length, or the base protocol header overhead, or the number of bytes in the base protocol header.

[0091] In some embodiments, in RoCE scenarios, each data packet actually transmitted in the network not only contains business data, but also carries basic protocol headers such as Ethernet, Internet Protocol (IP), User Datagram Protocol (UDP), InfiniBand, and RNIC checksum fields.

[0092] In some embodiments, the basic header consists of: a 14-byte Ethernet header, a 20-byte IPv4 header, an 8-byte UDP header, a 16-byte InfiniBand transport header, and a 4-byte RNIC checksum field, totaling 62 bytes, which are collectively denoted as BH. Therefore, in this embodiment, the basic protocol header overhead for each actual data packet is 62 bytes, and the total overhead or length of the basic protocol headers for all N packets is N×BH.

[0093] In some embodiments, each of the above data packets corresponds to a basic header / basic protocol header, and the first traffic information is the accumulated value of the basic header overhead.

[0094] In this way, the fixed overhead in the communication process of this work request can be calculated in advance to obtain accurate traffic prediction information.

[0095] Step 203: The traffic prediction device determines the second traffic information corresponding to the first data based on the transmission operation type and destination address corresponding to the first data.

[0096] In some embodiments, the transmission operation type corresponding to the first data includes any one of the following: send operation, RDMA write operation, and RDMA read operation.

[0097] In some embodiments, the traffic prediction device determines the destination and source of the first data transmission process based on the transmission operation type and destination address, and then calculates the overhead of the data transmission process according to the conventions of different transmission directions to obtain the second traffic information corresponding to the first data.

[0098] In some embodiments, combined with Figure 2 ,like Figure 5 As shown, step 203 can be implemented through steps 203a to 203c.

[0099] Step 203a: The flow prediction device determines the destination and source of the first data transmission based on the destination address.

[0100] In some embodiments, the traffic prediction device obtains the transmission direction of the first data based on the destination address of the first data, and determines the destination and source of the first data transmission based on the transmission direction.

[0101] Step 203b: The flow prediction device calculates the third flow information of the first data from the source to the destination and the fourth flow information of the first data from the destination to the source based on the destination and source of the first data and the transmission operation type.

[0102] Step 203c: The flow prediction device determines the second flow information corresponding to the first data based on the third flow information and the fourth flow information.

[0103] In one possible embodiment, if the transmission operation type information includes a send operation, the first data is sent from the source to the destination, and the destination sends an acknowledgment (ACK) message back to the source to confirm the data.

[0104] For example, the overhead of the first data being sent from the source to the destination is the overhead corresponding to the first traffic information, i.e., the fourth traffic information. The overhead of the ACK information is the length of a basic header and the length of an ACK Extended Transport Header (AETH), i.e., the third traffic information. By adding the overhead of the first traffic information and the overhead of the ACK information, the traffic overhead of this first data transmission can be obtained, i.e., the second traffic information.

[0105] In another possible embodiment, when the transmission operation type information includes an RDMA write operation, in addition to sending the actual data of the first data packet from the source to the destination, an RDMA Extended Transport Header (RETH) needs to be attached to the first data packet. Furthermore, the destination will also send an ACK message back to the source to acknowledge receipt.

[0106] For example, the cost of sending the first data from the source to the destination is the cost corresponding to the first traffic information plus one RETH, which is the fourth traffic information. The cost of the ACK information is a basic header length and an AETH length, which is the third traffic information. By combining the fourth traffic information and the third traffic information, the traffic cost of this first data transmission can be obtained, which is the second traffic information.

[0107] In another possible embodiment, where the transmission operation type information includes an RDMA read operation, the interaction direction is reversed compared to the previous two possible embodiments. The source needs to send a read request to the destination first, which includes a base header and an RETH. Then, the destination transmits the first data to the source, and needs to include an AETH to confirm the request sequence number.

[0108] For example, the overhead of the source sending a read request to the destination is a base header length plus a RETH length, which is the fourth traffic information mentioned above. The overhead of the destination returning the first data to the source is the overhead corresponding to the first traffic information plus an AETH length. By combining the fourth traffic information and the third traffic information, the traffic overhead of this first data transmission can be obtained, which is the second traffic information mentioned above.

[0109] In this way, the predicted number of bytes for the RDMA work request in the "source address → destination address" direction and the "destination address → source address" direction can be obtained respectively, and recorded as the transmission prediction value and the reception prediction value, thereby improving the accuracy of traffic prediction.

[0110] Step 204: The flow prediction device predicts the target flow information based on the first flow information and the second flow information.

[0111] In some embodiments, the target traffic information is the traffic information when transmitting the first data through the RDMA communication link.

[0112] In some embodiments, the target traffic information mentioned above includes at least one of the following: source address, destination address, transmitted traffic from source to destination, and received traffic from destination to source.

[0113] In the traffic prediction method provided in this application, the traffic prediction process can be directly triggered when the RDMA working request is received, so that traffic calculation for data transmission can be performed before the data enters the network, and the corresponding network resources can be allocated and scheduled for the data transmission process based on the traffic prediction calculation results, thereby ensuring the efficiency of data transmission.

[0114] The traffic prediction method of this application will be described below through specific embodiments.

[0115] The implementation process of the traffic prediction method provided in this application includes the following steps S1 to S11:

[0116] S1: The traffic prediction device triggers the traffic prediction process at the RDMA Verbs transmit interface.

[0117] In this embodiment, the prediction action is not performed after a packet has already appeared in the network, but is triggered immediately when the application submits an RDMA send request, i.e., the aforementioned RDMA work request.

[0118] Specifically, when an application calls ibv_post_send to submit a work request to a specified QP, the predictive agent embedded in the Verbs framework is activated by an event.

[0119] Understandably, ibv_post_send was chosen as the entry point because RDMA's SEND, WRITE, and READ requests are all submitted to the RNIC through this interface, and at this moment, the data has not yet actually been sent to the network. Therefore, it ensures the predictability in advance without requiring modifications to the application itself. In other words, this embodiment does not require the business application to explicitly report traffic demands; instead, it directly intercepts existing requests in the underlying software stack, thereby achieving a deployment method that is transparent to upper-layer applications.

[0120] In practice, the implementation logic of ibv_post_send can be modified or extended to insert prediction logic before it processes the original sending request.

[0121] For example, the prediction logic described above first records the QP handle associated with the current request and obtains a pointer to the work request structure. Since a work request has fully described the RDMA operation type used in this communication, the hash table containing the data to be sent, and the relevant control parameters, the purpose of this step is to establish the entry point for subsequent reading, calculation, and reporting. After completing this step, the system enters the parameter reading phase.

[0122] S2: The flow prediction device reads the data segment length information and transmission operation type information from the RDMA work request.

[0123] After ibv_post_send is triggered, this embodiment first reads two types of information directly related to the prediction from the work request structure in its input parameters: one is the data involved in this request, that is, the total length of the first data segment mentioned above, and the other is the transmission operation type used in this request.

[0124] For example, RDMA Verbs use the ibv_send_wr data structure to record a send RDMA work request. The sg_list member stores the address and length information of the data segment to be sent, while the opcode member stores the transmission opcode corresponding to the current work request. By copying or parsing these two members, the raw input necessary for subsequent traffic calculations can be obtained.

[0125] In practice, the traffic prediction device iterates through each data segment description item in sg_list, reads the length field of each segment, and temporarily stores the length of all data segments in the prediction context on the local host side.

[0126] It is understood that this embodiment does not concern itself with the data content, but only with the length information. Therefore, it will not introduce the parsing of the business load content, nor will it disrupt the data transmission path.

[0127] In practice, for the transmission type, the traffic prediction device directly determines from the opcode whether the request belongs to SEND, RDMA WRITE, or RDMA READ.

[0128] Understandably, different operation types determine the data flow, additional message headers, and acknowledgment message format between the communicating parties. Therefore, this field not only distinguishes business semantics but also directly determines the calculation formula for subsequent bidirectional traffic. Simultaneously, this step also needs to retain the QP handle associated with the work request for the next step to query the context attributes of that QP.

[0129] S3: The flow prediction device obtains the destination address and path MTU based on the QP handle.

[0130] For example, the hash table length and opcode in the work request alone are insufficient to fully calculate the number of messages and network load, because the destination identifier and MTU in the transmission path are still missing. Therefore, after reading the RDMA work request, this embodiment continues to use the QP handle associated with the current request to obtain the corresponding QP context information to obtain the destination address and MTU.

[0131] S4: The flow prediction device summarizes the lengths of all data segments and calculates the transmitted data, i.e., the total amount of data in the first data mentioned above.

[0132] For example, after the traffic prediction device completes parameter extraction, it enters the traffic calculation stage. First, it is necessary to determine the total amount of data actually involved in this work request, i.e., the total length of the first data mentioned above. Although the sg_list in the work request may contain multiple discrete data segments, in the RDMA protocol, these data from different segments can be continuously encapsulated and mapped into a set of messages to be transmitted. Therefore, the calculation basis for the number of messages is not the "number of segments," but the "sum of the lengths of all segments." This total length is denoted as DL, which is obtained by summing the lengths of all the aforementioned data segments.

[0133] In practical implementation, the flow prediction device can perform an accumulation operation on the length of each data segment in sg_list to obtain DL.

[0134] For example, if the current work request contains three scattered data segments with lengths L1, L2, and L3, the total data length is DL = L1 + L2 + L3. This total length represents the total number of bytes of data that will participate in this RDMA interaction from the source's perspective, and it forms the basis for subsequent fragmentation, header overlay, and bidirectional traffic estimation.

[0135] It should be noted that the calculation here is for the number of bytes of the original business data to be carried, excluding any network headers and control information. These protocol overheads will be further added in subsequent steps.

[0136] S5: The flow prediction device calculates the number of messages based on the total data length and MTU.

[0137] For example, after obtaining the total data length (DL) and path MTU, this embodiment further calculates how many data packets this communication will be divided into.

[0138] For example, the number of data packets N is calculated as follows: N = ceil(DL / MTU).

[0139] For example, the above formula means that when the total data length is not divisible by the MTU, an additional message is still needed to carry the remaining data, so the integer value is taken. N plays a crucial role because it directly determines how many times the basic message header needs to be appended, thus affecting the total number of bytes injected into the network.

[0140] For example, when DL=4096 bytes and MTU=1024 bytes, the data will be divided into N=4 packets; if DL=4100 bytes, then N=5 packets are still required. In other words, even a very small number of extra bytes will trigger a complete packet and its basic header overhead.

[0141] In this embodiment, the determination of N is not a formalized step, but a core intermediate variable that determines the number of header bytes of the basic protocol, confirms the traffic scale, and the total amount of bidirectional communication. Therefore, it must be clearly defined separately in the method flow.

[0142] S6: The traffic prediction device calculates the basic protocol header overhead that each data packet must carry.

[0143] For example, in this embodiment, the basic protocol header overhead of each actual data packet is 62 bytes, and the total basic protocol header overhead of all N data packets is N×BH.

[0144] In practice, after obtaining the number of data packets N, the traffic prediction device directly calculates the fixed overhead caused by the basic protocol in this communication based on BH=62 bytes.

[0145] Understandably, this overhead is independent of the specific payload content but strictly related to the number of messages, making it particularly important in high-concurrency, small-message scenarios. Adding N×BH to the DL obtained from S4 yields the basic transmission scale "without considering RDMA operation-specific control headers and acknowledgment messages." Subsequently, this embodiment further incorporates the additional headers and reverse control traffic corresponding to SEND, WRITE, and READ, based on the specific operation type.

[0146] S7: The flow prediction device calculates the bidirectional flow from source to destination and from destination to source according to the RDMA operation type.

[0147] This embodiment does not use a uniform formula to roughly estimate all RDMA operations, but instead models them strictly according to the actual interaction mechanisms of the three operations: SEND, RDMAWRITE, and RDMAREAD. This is because the message direction, additional extension headers, and acknowledgment methods differ between the three operations. Failure to differentiate these would lead to a systematic deviation between the predicted results and the actual number of bytes injected into the network. The bidirectional flow formulas for the three operations and the relevant extension header fields are as follows: the ACK extension header (AETH) is 4 bytes long, and the Remote Extension Transport header (RETH) is 16 bytes long.

[0148] Firstly, for the SEND operation, the source sends business data to the destination, and the destination returns an ACK upon receipt to acknowledge receipt. The SEND data packet itself does not carry an additional RDMA extension header; therefore, the traffic from the source to the destination consists of the original data and N basic headers, i.e., DL + N × BH, which is the fourth type of traffic information mentioned above. The acknowledgment traffic returned by the destination consists of one basic header and one AETH, i.e., BH + AETH, which is the third type of traffic information mentioned above. Here, AETH is used to confirm the message sequence number and indicate a positive or negative acknowledgment status. In other words, for SEND, the request direction mainly carries business data, while the response direction only bears the acknowledgment overhead.

[0149] Secondly, for RDMA WRITE operations, in addition to sending the actual data to the destination, the source end also needs to attach a RETH header to the first data packet. This header is used to indicate the virtual address and access protection key information of the destination's remote memory buffer. This RETH is only attached once, rather than being repeatedly attached to every packet. Therefore, the total traffic from the source to the destination is DL + N × BH + RETH, which is the fourth traffic information mentioned above. The acknowledgment traffic from the destination to the source is similar to SEND, still BH + AETH, which is the third traffic information mentioned above. The characteristic of this operation is that data and remote write control information are sent unidirectionally from the source to the destination, and the destination only returns a brief acknowledgment.

[0150] Thirdly, for RDMA READ operations, the interaction direction is reversed compared to the previous two: the source first sends a read request to the destination. This request message includes a basic header and a RETH, indicating the address of the destination remote buffer and access control information to be read; the actual data is then returned from the destination to the source. When returning data, the destination returns the original data and N basic headers, along with an AETH to confirm the request sequence number. Therefore, the calculation formula is: the request-direction traffic from the source to the destination is BH + RETH, which is the fourth traffic information mentioned above; the data return-direction traffic from the destination to the source is DL + N × BH + AETH, which is the third traffic information mentioned above. It is evident that in READ operations, the large traffic volume occurs in the return direction, not the request direction.

[0151] Therefore, in this embodiment, after identifying the opcode, the traffic prediction device performs conditional calculations as follows: when the opcode corresponds to SEND, the SEND bidirectional traffic formula is used; when the opcode corresponds to RDMA WRITE, the WRITE bidirectional traffic formula is used; and when the opcode corresponds to RDMA READ, the READ bidirectional traffic formula is used.

[0152] S8: The flow prediction device generates a single flow prediction result table item.

[0153] For example, after completing the bidirectional byte count calculation, the traffic prediction device organizes the current work request into a reportable prediction result entry, namely the aforementioned target traffic information. A single entry should at least include the following fields: source address, destination address, transmitted traffic from source to destination, and received traffic from destination to source. In engineering implementations, the entry may also include auxiliary fields such as timestamps, QP numbers, operation types, or sequence numbers; however, in terms of the core inventive concept, it should at least be able to express "how much bidirectional traffic will occur between which two hosts".

[0154] For example, since a traffic prediction device may continuously initiate multiple work requests within a short period of time, this embodiment does not immediately upload each request individually in a high-overhead manner. Instead, it writes each entry into the host-side prediction result table. This prediction result table can be understood as a temporary set of traffic that will be generated in the short term in the future, where each entry corresponds to a stream that has already been parsed. On the same source host, if multiple work requests point to the same destination host, subsequent implementations may choose to pre-aggregate them before reporting. However, even without pre-aggregation, the method of this embodiment remains valid.

[0155] S9: The flow prediction device writes the prediction results into shared memory and performs a reporting.

[0156] For example, to reduce the overhead of cross-process data copying, a shared memory block is allocated on each host to store the prediction results. After the traffic prediction device generates a single flow entry, it writes the entry into the prediction result area in the local shared memory; independent reporting processes can directly read data from this shared memory and send it to the central control node. The advantage of this approach is that it avoids repeatedly copying prediction data between different processes, saving CPU overhead and providing conditions for the subsequent scheduling module to obtain prediction results more quickly.

[0157] In practice, the shared memory can store multiple prediction entries in a table structure order or organized in a circular queue. After the prediction agent completes a write operation, it can trigger the reporting thread through event notification, polling checks, or batch sending after reaching a preset threshold. The reporting thread reads the valid entries in the shared memory, forms a local prediction result table, and sends it to the central control node via out-of-band control signaling. Here, "out-of-band" means that the prediction result reporting does not share the same data channel as the actual business data flow, thereby avoiding interference between the prediction process and the business flow.

[0158] S10: The traffic prediction device aggregates the prediction results from each host through the central control node to form a global traffic matrix.

[0159] At the network level, this embodiment does not merely obtain local predictions from a single host's perspective. Instead, it aggregates the results reported by all hosts through a central control node to construct a global traffic matrix for the entire data center. Aggregation logic: Each reported record contains at least the source address, destination address, transmitted traffic, and received traffic. The central control node iterates through the prediction result tables reported by each host, performing matrix accumulation in two directions for each flow item: accumulating transmitted traffic to TM(src,dst) and accumulating received traffic to TM(dst,src). Thus, each element in the matrix represents the predicted traffic volume from one host to another over a future period.

[0160] For example, if host A reports a record indicating that its predicted traffic for a certain work request to host B is X bytes for A→B and Y bytes for B→A, then the central control node will increment TM(A,B) by X and TM(B,A) by Y. If subsequent requests also involve the same pair of hosts, the increments will continue. By performing the same processing on all prediction records for all hosts, a complete inter-host predicted traffic matrix can be formed. This matrix can be directly used by modules such as load balancers, rate shapers, and traffic engineering controllers to formulate network optimization strategies in advance.

[0161] S11: Method output and its uses.

[0162] After completing the above aggregation, the final output of this embodiment is not a local statistical value of a single job request, but a global prediction result that can characterize the short-term traffic distribution of the network in the future. This result includes at least: the predicted transmitted traffic between each source host and each destination host, the corresponding reverse traffic, and the host-level traffic matrix formed thereby. Since these results are obtained before the data actually enters the network, the controller can pre-compile control actions such as path reselection, bandwidth reservation, queue shaping, or load migration before the traffic arrives, thereby alleviating congestion, improving completion time, and optimizing network resource utilization. The central controller can be co-located with network optimization modules such as load balancers and rate shapers, providing these optimization modules with the required predicted traffic matrix.

[0163] It should be noted that the method provided in this embodiment can be divided into a triggering and capturing step, a parameter reading step, a context acquisition step, a traffic calculation step, a result generation step, and a centralized aggregation step, namely the process from steps S1 to S11 above. Among them, the first five steps are completed on the host side that initiates the RDMA request, and the last step is completed on the central control node.

[0164] The following complete embodiment further illustrates how the method of this embodiment can be implemented.

[0165] Suppose that an application on host H1 initiates an RDMA WRITE request (i.e., an RDNA work request) to host H2 through a certain QP. The RDNA work request contains two data segments with lengths of 1500 bytes and 800 bytes respectively (the first data segment mentioned above). Then, in S2, the traffic prediction device reads the two segments from sg_list and calculates the total data length DL = 2300 bytes. Simultaneously, it identifies the request as an RDMAWRITE operation from the opcode.

[0166] Subsequently, in S3, the RDNA work request obtains the destination address as the network address of host H2 and the path MTU as 1024 bytes by querying or hitting the cache based on the QP handle associated with the request. Upon entering S5, the number of packets is calculated as N = ceil(2300 / 1024) = 3. Based on the RoCE base header size, the total overhead of the base header is 3 × 62 = 186 bytes. Since it is an RDMA WRITE operation, an additional 16-byte RETH packet is required in the source-to-destination direction, while a BH + AETH = 62 + 4 = 66-byte acknowledgment packet is needed in the destination-to-source direction.

[0167] Therefore, the predicted result for this request is: the total traffic from H1 to H2 is 2300 + 186 + 16 = 2502 bytes, and the total traffic from H2 to H1 is 66 bytes.

[0168] Subsequently, host H1 writes an entry containing the source address H1, destination address H2, 2502 bytes of transmitted traffic, and 66 bytes of received traffic into its local shared memory, and then sends it to the central control node via the reporting process. Upon receiving this result, the central control node increments TM(H1,H2) by 2502 and TM(H2,H1) by 66 in the traffic matrix. This completes the entire process from job request capture, parameter extraction, traffic calculation to matrix aggregation.

[0169] Thus, this embodiment provides a communication traffic prediction method for RDMA networks, which can determine the bidirectional traffic scale corresponding to the communication request at the communication request submission stage, thereby solving the problem in the prior art that it is impossible to obtain accurate traffic information before data transmission:

[0170] (1) A method is provided that can characterize traffic at the granularity of communication requests, thereby solving the problem that the granularity of traffic statistics in the prior art is too coarse and it is difficult to reflect the characteristics of a single request;

[0171] (2) A traffic calculation method that combines the differences in RDMA communication operation types is provided to solve the problem of lack of accurate modeling for different RDMA operations in the prior art;

[0172] (3) A method for constructing a global traffic matrix based on request-level prediction results is provided, thereby solving the problem that the traffic matrix in the prior art relies on historical statistics and lacks foresight.

[0173] It should be noted that the descriptions of each step S1 to S11 in this embodiment can be found in the descriptions in the above embodiments, and will not be repeated here.

[0174] The communication traffic prediction method for RDMA networks proposed in this invention is implemented based on existing RDMA programming interfaces and host-side software mechanisms, and is specifically reflected in the following five aspects:

[0175] (1) The key input information used in this embodiment all come from the standard RDMA Verbs interface, including obtaining the work request structure through ibv_post_send and obtaining the queue pair context information through ibv_query_qp. The above interfaces are all standard interfaces that are widely supported in the existing RDMA software stack. No modification is required to the underlying hardware protocol or network device. The relevant functions can be implemented by simply extending or encapsulating the software on the host side.

[0176] (2) This embodiment intercepts and processes application calls by embedding prediction logic at the RDMA transmission interface. It does not require modification of the upper-layer business code, nor does it rely on the application actively reporting traffic information. Therefore, in actual deployment, it can be implemented through library replacement, function interception, or driver layer extension, with minimal impact on existing business systems.

[0177] (3) The traffic prediction process in this embodiment mainly includes data segment length accumulation, packet number calculation and simple arithmetic operations. It does not involve complex optimization solutions or large-scale state maintenance, and the computational complexity is low. At the same time, by introducing QP context caching on the host side, the extra overhead caused by frequent calls to the query interface can be avoided, thereby ensuring that the impact of the prediction process on CPU and latency is within a controllable range.

[0178] (4) This embodiment adopts an architecture that combines distributed prediction on the host side with centralized aggregation at the central node. Each host independently completes the traffic calculation at the communication request level and only needs to report the prediction results. This method does not rely on global synchronization or centralized calculation, can adapt to large-scale data center environments, and can be linearly scaled as the number of nodes increases.

[0179] (5) The prediction results output by this embodiment are the traffic information between the source node and the destination node and the global traffic matrix. They can be directly used as input for existing network control modules such as load balancing, traffic engineering, rate control or path optimization without changing the existing network control logic, and have good system compatibility.

[0180] It should be noted that the above-described method embodiments, or the various possible implementations of the method embodiments, can be executed individually, or, provided there is no conflict, they can be combined with each other. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0181] It should be noted that for a detailed explanation of the steps performed by each module and their beneficial effects, please refer to the description in the above embodiments, which will not be repeated here.

[0182] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0183] This application embodiment can divide the traffic prediction device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0184] In some embodiments, this application also provides a traffic prediction apparatus. The traffic prediction apparatus may include one or more functional modules for implementing the traffic prediction method of the above method embodiments.

[0185] For example, Figure 6 This is a schematic diagram of a flow prediction device provided in an embodiment of this application. Figure 6As shown, the traffic prediction device 900 includes: an acquisition module 901, a processing module 902, and a prediction module 903. The acquisition module 901, upon receiving an RDMA work request, acquires the destination address and MTU in the transmission path corresponding to the QP handle associated with the RDMA work request, based on the QP handle of the QP associated with the RDMA work request. The RDMA work request requests the transmission of first data through an RDMA communication link, and the RDMA work request includes the data segment length and transmission operation type of the first data. The processing module 902, based on the data segment length and the MTU, determines first traffic information corresponding to the first data. The processing module 902 is also used to determine second traffic information corresponding to the first data based on the transmission operation type and the destination address. The prediction module 903, based on the first traffic information and the second traffic information, predicts target traffic information, which is the traffic information when the first data is transmitted through the RDMA communication link.

[0186] In the traffic prediction device provided in this application embodiment, the traffic prediction process can be directly triggered when the RDMA working request is received, so that traffic calculation for data transmission can be realized before the data enters the network, and the corresponding network resources are allocated and scheduled for the data transmission process based on the traffic prediction calculation results, thereby ensuring the efficiency of data transmission.

[0187] In some embodiments, the processing module 902 is specifically used to: calculate the total data length of the first data based on the data segment length; generate at least one data packet corresponding to the first data based on the total data length and the MTU; and calculate the first traffic information corresponding to the first data according to the basic header length corresponding to each data packet.

[0188] In some other embodiments, the processing module 902 is specifically used to: determine the destination and source of the first data based on the destination address; calculate the third flow information of the first data from the source to the destination and the fourth flow information of the first data from the destination to the source based on the destination and source of the first data and the transmission operation type; and determine the second flow information corresponding to the first data based on the third flow information and the fourth flow information.

[0189] In another set of embodiments, the above-mentioned transmission operation type includes any one of the following: transmit operation, RDMA write operation, and RDMA read operation.

[0190] In another embodiment, the acquisition module 901 is specifically used to: if the query result corresponding to the QP is found in the local cache, acquire the QP context information corresponding to the QP handle; or, if the query result corresponding to the QP is not found in the local cache, call the first interface to query the QP context information in the remote direct memory access network card RNIC; wherein the QP context information includes the destination address and the MTU.

[0191] It should be noted that the flow prediction device can implement all the processes implemented in the above method embodiments and achieve the same beneficial effects. To avoid repetition, it will not be described again here.

[0192] In the case where the functions of the integrated modules described above are implemented in hardware, this application provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 7 As shown, the electronic device 90 includes: a processor 92, a communication interface 93, and a bus 94. Optionally, the electronic device 90 may also include a memory 91.

[0193] Processor 92 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0194] Communication interface 93 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0195] The memory 91 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0196] As one possible implementation, the memory 91 can exist independently of the processor 92. The memory 91 can be connected to the processor 92 via a bus 94 and is used to store instructions or program code. When the processor 92 calls and executes the instructions or program code stored in the memory 91, it can implement the traffic prediction method provided in the embodiments of this application.

[0197] In another possible implementation, memory 91 can also be integrated with processor 92.

[0198] Bus 94 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 94 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0199] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

[0200] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described traffic prediction method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0201] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0202] This application also provides a readable storage medium storing a program or instructions that, when executed by a computer, implement the traffic prediction method provided in the above embodiments. It is understood that all or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; the readable storage medium can be any of the foregoing embodiments or memory; the readable storage medium can also be an external storage device of the service invocation device, such as a pluggable hard drive, Smart MediaCard (SMC), Secure Digital (SD) card, flash card, etc., equipped on the service invocation device. Further, the readable storage medium can include both internal storage units of the service invocation device and external storage devices. The readable storage medium is used to store the computer program and other programs and data required by the service invocation device. The readable storage medium can also be used to temporarily store data that has been output or will be output.

[0203] This application also provides a computer program product, which is stored in a storage medium and implements the traffic prediction method provided in the above embodiments when the computer program product is executed by a computer.

[0204] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0205] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0206] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A flow prediction method, characterized in that, include: Upon receiving a Remote Direct Memory Access (RDMA) work request, based on the QP handle of the queue pair QP associated with the RDMA work request, the destination address and the maximum transmission unit (MTU) in the transmission path corresponding to the QP handle are obtained. The RDMA work request is used to request the transmission of first data through the RDMA communication link. The RDMA work request includes the data segment length and transmission operation type of the first data. Based on the data segment length and the MTU, the first traffic information corresponding to the first data is determined; Based on the transmission operation type and the destination address, determine the second traffic information corresponding to the first data; Based on the first traffic information and the second traffic information, target traffic information is predicted, wherein the target traffic information is the traffic information when the first data is transmitted through the RDMA communication link.

2. The flow prediction method according to claim 1, characterized in that, The step of determining the first traffic information corresponding to the first data based on the data segment length and the MTU includes: Based on the data segment length, calculate the total data length of the first data; Based on the total data length and the MTU, at least one data packet corresponding to the first data is generated; The first traffic information corresponding to the first data is calculated based on the basic header length of each data packet.

3. The flow prediction method according to claim 1, characterized in that, The step of determining the second traffic information corresponding to the first data based on the transmission operation type and the destination address includes: Based on the destination address, determine the destination and source ends for transmitting the first data; Based on the destination and source of the first data transmission and the transmission operation type, the third flow information of the first data from the source to the destination and the fourth flow information of the first data from the destination to the source are calculated respectively. Based on the third and fourth traffic information, the second traffic information corresponding to the first data is determined.

4. The flow prediction method according to claim 3, characterized in that, The transmission operation type includes any of the following: send operation, RDMA write operation, and RDMA read operation.

5. The flow prediction method according to claim 1, characterized in that, The process of obtaining the MTU in the destination address and transmission path corresponding to the QP handle associated with the RDMA work request includes: If the query result corresponding to the QP is retrieved from the local cache, obtain the QP context information corresponding to the QP handle; or... If no query result corresponding to the QP is found in the local cache, the first interface is called to query the QP context information in the remote direct memory access network interface card (RNIC). The QP context information includes the destination address and the MTU.

6. A flow prediction device, characterized in that, include: The module includes an acquisition module, a processing module, and a prediction module. The acquisition module is used to, upon receiving a Remote Direct Memory Access (RDMA) work request, acquire the destination address and the maximum transmission unit (MTU) in the transmission path corresponding to the QP handle based on the QP handle of the queue pair QP associated with the RDMA work request. The RDMA work request is used to request the transmission of first data through the RDMA communication link. The RDMA work request includes the data segment length and transmission operation type of the first data. The processing module is used to determine the first traffic information corresponding to the first data based on the data segment length and the MTU; The processing module is further configured to determine the second traffic information corresponding to the first data based on the transmission operation type and the destination address; The prediction module is used to predict target traffic information based on the first traffic information and the second traffic information, wherein the target traffic information is the traffic information when the first data is transmitted through the RDMA communication link.

7. The flow prediction device according to claim 6, characterized in that, The processing module is specifically used for: Based on the data segment length, calculate the total data length of the first data; Based on the total data length and the MTU, at least one data packet corresponding to the first data is generated; The first traffic information corresponding to the first data is calculated based on the basic header length of each data packet.

8. The flow prediction device according to claim 6, characterized in that, The processing module is specifically used for: Based on the destination address, determine the destination and source ends for transmitting the first data; Based on the destination and source of the first data transmission and the transmission operation type, the third flow information of the first data from the source to the destination and the fourth flow information of the first data from the destination to the source are calculated respectively. Based on the third and fourth traffic information, the second traffic information corresponding to the first data is determined.

9. The flow prediction device according to claim 8, characterized in that, The transmission operation type includes any of the following: send operation, RDMA write operation, and RDMA read operation.

10. The flow prediction device according to claim 6, characterized in that, The acquisition module is specifically used for: If the query result corresponding to the QP is retrieved in the local cache, the QP context information corresponding to the QP handle is obtained; or, If no query result corresponding to the QP is found in the local cache, the first interface is called to query the QP context information in the remote direct memory access network interface card (RNIC). The QP context information includes the destination address and the MTU.

11. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the traffic prediction method as described in any one of claims 1 to 5.

12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a computer, implement the traffic prediction method as described in any one of claims 1 to 5.

13. A computer program product, characterized in that, The computer program product is stored in a storage medium, and when executed by a computer, the computer program product implements the traffic prediction method as described in any one of claims 1 to 5.

Images