Method and system for aggregation to achieve congestion management

Abstract

The present disclosure relates to converging to enable congestion management. A network interface controller (NIC) that facilitates incast management at a computing system is provided. During operation, the NIC can receive a request to send data from a remote computing system via a network. The NIC can determine that the request is one of a plurality of requests from a plurality of remote computing systems that are accessible via the network. Based on a descriptor in the request, the NIC can determine a storage location of the data at the remote computing system. Then, the NIC can determine a degree of congestion at the computing system associated with the plurality of requests. The NIC can schedule data retrieval in response to the request based on the degree of congestion and with respect to the plurality of requests. Then, the NIC can retrieve the data from the storage location based on remote access.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 379,079, Agent’s File No. P170847USPRV, filed on October 11, 2022, entitled “Systems and Methods for Implementing Congestion Management and Encryption” by inventors Keith D. Underwood and Duncan Roweth. Technical Field

[0003] This disclosure generally relates to data transmission. Background Technology

[0004] High-performance computing (HPC) typically facilitates efficient computation on the nodes running applications. HPC can also facilitate high-speed data transfer between sending and receiving devices. Summary of the Invention

[0005] In one aspect, this disclosure provides a computing system comprising: a memory device; and a network interface controller (NIC) configured to: receive, via a network, a first request to send the first data to a remote computing system storing the first data, wherein the network includes a high-performance computing (HPC) architecture that supports retrieval of the first data based on a convergence protocol supported by the HPC architecture, and wherein the convergence protocol supports sending the first request for the first data and retrieval of the first data based on remote memory access; determine that the first request is one of a plurality of requests to send data to the computing system received from a plurality of remote computing systems accessible via the network; determine a storage location of the first data at the remote computing systems based on a descriptor in the first request; determine the number of the plurality of requests as an incast level at the computing systems; schedule the time for retrieval of the first data in response to the first request based on the incast level and relative to the plurality of requests; and retrieve the first data from the storage location at the remote computing systems at the scheduled time based on the convergence protocol.

[0006] In one aspect, this disclosure provides a method for data transmission, comprising: receiving, via a network, a first request by a receiving device to send the first data to a sending device, from an application running on a sending device storing the first data, wherein the network includes a high-performance computing (HPC) architecture that supports retrieval of the first data based on a convergence protocol supported by the HPC architecture, and wherein the convergence protocol supports sending the first request for the first data and retrieval of the first data based on remote memory access; determining that the first request is one of a plurality of requests to send data to the receiving device from a plurality of sending devices accessible via the network; determining, based on a descriptor in the first request, a storage location of the first data at the sending device; determining the number of the plurality of requests as an incast level at the receiving device; scheduling, by the receiving device, a time for retrieval of the first data in response to the first request based on the incast level and relative to the plurality of requests; and retrieving, by the receiving device, the first data from the storage location at the sending device at the scheduled time based on the convergence protocol.

[0007] In one aspect, this disclosure provides a non-transitory computer-readable storage medium including instructions that, when executed on a network interface controller (NIC) of a receiving device in a distributed system, cause the NIC to: receive, via a network, a first request to send the first data to a sending device from a sending device storing the first data, wherein the network includes a high-performance computing (HPC) architecture that supports retrieval of the first data based on a convergence protocol supported by the HPC architecture, and wherein the convergence protocol supports sending the first request for the first data and retrieval of the first data based on remote memory access; determine that the first request is one of a plurality of requests to send data to the receiving device that can be received from a plurality of sending devices accessible via the network; determine, based on a descriptor in the first request, a storage location of the first data at the sending device; determine the number of the plurality of requests as an incast level at the receiving device; schedule the time for retrieval of the first data in response to the first request based on the incast level and relative to the plurality of requests; and retrieve the first data from the storage location at the sending device to the NIC at the scheduled time based on the convergence protocol. Attached Figure Description

[0008] Figure 1A An example of receiver-driven incast management for data acquisition according to one aspect of this application is illustrated.

[0009] Figure 1B An example of obtaining disordered data according to one aspect of this application is illustrated.

[0010] Figure 2 A flowchart according to one aspect of this application is presented, illustrating an example of a network interface controller (NIC) of a computing system using convergence to implement congestion management.

[0011] Figure 3 An example of receiver-driven incast-managed communication according to one aspect of this application is illustrated.

[0012] Figure 4A A flowchart according to one aspect of this application is presented, illustrating an example of a receiving device scheduling data retrieval in response to a transmission request.

[0013] Figure 4B A flowchart according to one aspect of this application is presented, illustrating an example of a process by which a receiving device obtains a copy of data from a sending device at a scheduled time.

[0014] Figure 5 A flowchart according to one aspect of this application is presented, illustrating an example of a process in which a sending device sends a transmission request to a receiving device.

[0015] Figure 6 An example of a computing system for receiver-driven incast management that facilitates the use of data acquisition, according to one aspect of this application, is illustrated.

[0016] Figure 7 An example of a nontransitory computer-readable storage device for receiver-driven incast management that facilitates data acquisition according to one aspect of this application is illustrated.

[0017] In these accompanying drawings, the same reference numerals refer to the same elements. Detailed Implementation

[0018] As applications become increasingly distributed, HPC facilitates efficient computation on the nodes running those applications. An HPC environment can include compute nodes, storage nodes, and high-capacity switches coupling these nodes. Typically, compute nodes can form clusters. These clusters can be coupled to storage nodes via a network. Compute nodes can run one or more applications in parallel within the cluster. Storage nodes can record the output of computations performed on the compute nodes. Therefore, compute and storage nodes can work together to promote high-performance computing.

[0019] To ensure the expected performance levels, nodes need to operate at the same rate as other nodes. For example, after a compute node generates data, a storage node needs to immediately receive a copy of the data from the compute node. Here, the storage node and compute node can operate as a receiver and sender, respectively. Conversely, if a compute node receives data from a storage node, the storage node and compute node can operate as a sender and receiver, respectively. Furthermore, network switches need to transmit data at high speeds to guarantee low-latency data delivery. When many sender devices attempt to send data to receiver devices, incast occurs in the network, leading to high congestion at the receiver devices. Therefore, high-performance networks (such as data center networks) may require mechanisms to mitigate congestion during incast to ensure high-speed data delivery.

[0020] The aspects described herein address the problem of efficient data transfer in a network during incast at the receiving device by: (i) obtaining a data descriptor from a transmission request received from the sending device; (ii) scheduling the corresponding file retrieval based on the congestion level at the receiving device; and (iii) remotely retrieving the data from the location indicated in the descriptor at the scheduled time. Because the receiving device is aware of all transmission requests from multiple sending devices, it can efficiently determine when to retrieve data from each data set. To this end, the receiving device can schedule retrievals to avoid conflicts between them. When the receiving device is ready to retrieve a data set from a specific sending device, it can use Remote Direct Memory Access (RDMA) to retrieve the data without interacting with the corresponding application on the sending device.

[0021] In existing technologies, data transmission from multiple sending devices to receiving devices can lead to congestion and reduce the throughput of data streams at switches. This many-to-one communication pattern can be called "incast." Typically, to mitigate the effects of incast, the receiving device can limit the traffic from the sending devices. The receiving device can then schedule transmissions from the sending devices and send transmission credits to each sending device based on the scheduling. Credits allow the sending devices to transmit data to the receiving device, as indicated by the corresponding credit. However, since the receiving device cannot control how the sending devices schedule transmissions, switches in the network may still experience congestion.

[0022] Furthermore, to transmit data, the sending device may include data in packets. This can lead to packets arriving out of order at the receiving device. Out-of-order arrival may require packets to have sequence numbers. In some examples, data transmission over a network may require header information to be ordered. However, the payload data associated with the header information may not need to be ordered in the same way. Typically, data transmission can use a packet stream, where header information is included in packets along with payload data. In this case, packets are ordered according to the header information. Some existing congestion management solutions utilize multiple paths in the network, where the sending device sends packets on multiple paths to avoid congestion on a specific path. Therefore, both the sending and receiving devices must maintain numerous resource-intensive mechanisms to facilitate packet reordering. Incasts in the network can further exacerbate packet loss and place additional pressure on the packet reordering mechanism.

[0023] To address this issue, the receiving device can schedule the sending device's transmission based on its congestion level. The congestion level may depend on the incast level. Instead of granting transmission credits to the sending device and allowing the sending device to determine when to transmit, the receiving device can perform data retrieval operations directly from the sending device. Therefore, the receiving device can control when the retrieved data crosses the network. During operation, when a sending application on the sending device needs to send data to a corresponding application on the receiving device, the application can notify the NIC on the sending device. The sending device's NIC can be referred to as the sending NIC.

[0024] The sending NIC can then retrieve the data (e.g., from a memory location allocated to the application) and store it in the NIC's sender buffer. Subsequently, the sending NIC can send a transmission request to send the data. This request may include a data descriptor. The descriptor may indicate the location of the data. This location may include the memory location of the data in the sender buffer. When the receiving device's NIC (which may be referred to as the receiving NIC) receives the request, the receiving NIC can allocate a location in the NIC's receiveer buffer. The receiveer buffer may be allocated to the data stream associated with the data.

[0025] The receiving NIC can retrieve data from the location specified in the descriptor. The retrieval process can bypass active application intervention. The receiving NIC can use RDMA to retrieve data from the sender's buffer in the sending NIC. Because the receiving device can pull data from the sender's buffer instead of requesting the sender to send data, the receiving device can control when data arrives. Accordingly, the receiving device can schedule retrievals to avoid conflicts. By retrieval data based on scheduling, the receiving NIC can arrange how data from the sender NIC traverses the network. This efficient retrieval-based incast management system can mitigate the effects of incast and reduce congestion in the network.

[0026] Furthermore, the acquisition process can be integrated with a credit-based congestion management system. For example, when the congestion level at the receiving device reaches a threshold, the receiving device can switch from a credit-based system to an acquisition-based system. The congestion level can correspond to the incast level, which indicates the number of sending devices sending transmission requests to the receiving device. Accordingly, the threshold can indicate one or more of the following: a predetermined number of sending devices, and a predetermined utilization level or percentage of the receiving buffer from which data is received. For example, if the number of sending devices sending transmission requests reaches a predetermined number (i.e., the threshold), a switch to the acquisition-based system can be triggered. On the other hand, if the congestion level reaches a higher threshold (e.g., a high watermark), the receiving device can suspend data acquisition for a predetermined period of time. This allows the receiving device to clear pending transmissions. Subsequently, when the period expires and the congestion level drops below the higher threshold, the receiving device can restart the scheduling process.

[0027] Furthermore, the receiving device can maintain tracking of successfully acquired data. Specifically, since each piece of acquired data can be placed at a predetermined position in the receiving buffer, these positions can indicate the order of the received data. Accordingly, based on the position of a piece of acquired data in the receiving buffer, the receiving NIC can determine whether the data has arrived in order. If data is acquired out of order, it can be retained in its assigned position. When the receiving NIC receives all data in order, it can push the data to the application. Thus, out-of-order data acquisition reduces the need for a reordering mechanism at the receiving device.

[0028] In this disclosure, the term "switch" is used in a general sense and can refer to any standalone or structured switch operating at any network layer. "Switch" should not be construed as limiting the examples of the invention to Layer 2 networks. Any device that can forward traffic to external devices or other switches can be called a "switch". Any physical or virtual device (e.g., a virtual machine or switch operating on a computing device) that can forward traffic to end devices can be called a "switch". Examples of "switch" include, but are not limited to, Layer 2 switches, Layer 3 routers, routing switches, components of Gen-Z networks, or structured switches comprising multiple similar or heterogeneous smaller physical and / or virtual switches.

[0029] The term "packet" refers to a group of bits that can be transmitted together on a network. "Packet" should not be construed as limiting the examples of this invention to a specific layer of the network protocol stack. "Packet" may be replaced by other terms involving a group of bits, such as "message," "frame," "unit," "datagram," or "transaction." Furthermore, the term "port" can refer to a port that can receive or transmit data. "Port" can also refer to the hardware, software, and / or firmware logic that facilitates the operation of that port.

[0030] Figure 1A An example of receiver-driven incast management for data acquisition according to one aspect of this application is illustrated. An HPC environment 100 may include multiple nodes 111, 112, 113, 114, 115, 116, 117, 118, and 119. A subset of these nodes may be compute nodes, while the others may be storage nodes. These nodes may be coupled to each other via a network 110. The respective nodes may operate as receiver devices or transmitter devices. Such nodes may be referred to as receiver devices or transmitter devices, respectively. The network 110 may include a set of high-capacity switches 101, 102, 103, 104, and 105. Here, the network 110 may be an HPC architecture. Compute nodes and storage nodes can cooperate with each other through the network 110 to facilitate high-performance computing in the HPC environment 100.

[0031] A subset of switches in network 110 can be coupled to each other via their respective channels. Examples of channels may include, but are not limited to, VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization Using GRE (NVGRE), Geneve, Internet Protocol Security (IPsec), and Multiprotocol Label Switching (MPLS). Channels in network 110 can be formed on an underlying network (or lower-level network). The underlying network can be a physical network, and the corresponding links in the underlying network can be physical links. The corresponding switch pairs in the underlying network can be Border Gateway Protocol (BGP) peers. VPNs, such as Ethernet VPNs (EVPNs), can be deployed on network 110.

[0032] To ensure the expected performance level, the corresponding nodes in HPC environment 100 can operate at the same rate as other nodes. Assume node 111 operates as a receiving device. Then, at least a subset of the remaining nodes in environment 100 can operate as sending devices. Switches 101, 102, 103, 104, and 105 can facilitate high-speed, low-latency data transmission from the respective sending devices to receiving device 111. When a large number of sending devices attempt to send data to receiving device 111, incast occurs in network 110, which can lead to high congestion at receiving device 111 and the associated switches. Therefore, to ensure high-speed data transmission, HPC environment 100 may require mechanisms to mitigate congestion during incast.

[0033] In existing technologies, data transmission from multiple sending devices (such as sending devices 112 and 114) to a receiving device can lead to congestion and reduce the throughput of the data stream (e.g., at the switch 101 coupled to receiving device 111). When an incast occurs, receiving device 111 can limit the traffic from the sending devices to mitigate the impact of the incast. Receiving device 111 can then schedule the transmissions from the sending devices and send transmission credits to the respective sending devices, such as sending devices 112 and 114, based on the scheduling. The credits allow sending devices 112 and 114 to transmit data to receiving device 111, as indicated by the corresponding credit. However, since receiving device 111 has no control over how sending devices 112 and 114 can schedule the transmissions, the switch in network 110 may still experience congestion.

[0034] Furthermore, to transmit data, sending devices 112 and 114 can include data in a set of packets. However, due to the lossy nature of network 110, one or more packets may be lost. This may result in packets arriving out of order at receiving device 111. Out-of-order arrival may require packets to have sequence numbers. Therefore, sending devices 112 and 114, as well as receiving device 111, need to maintain a large number of resource-intensive mechanisms to facilitate packet reordering. Incasting in network 110 may further exacerbate packet loss in network 110 and put further stress on the packet reordering mechanism.

[0035] To address this issue, receiving device 111 can schedule transmissions from sending devices 112 and 114 based on the level of congestion at receiving device 111 (e.g., indicated by incast level). Instead of granting transmission credits to sending device 112 (or sending device 114) and allowing sending device 112 to determine when to transmit, receiving device 111 can perform data retrieval operations directly from sending device 112. Therefore, receiving device 111 can control when the retrieved data can traverse network 110. During operation, when a sending application on sending device 112 needs to send data 134 and 136 to receiving device 111, the application can notify the NIC 130 of sending device 112. Similarly, when a sending application on sending device 114 needs to send data 144 and 146 to receiving device 111, the application can notify the NIC 140 of sending device 114.

[0036] NIC 130 can then receive from sender device 112 an instruction indicating the memory locations of data 134 and 136 in the memory device 132 of sender device 112. Similarly, NIC 140 can receive from sender device 114 an instruction indicating the memory locations of data 144 and 146 in the memory device 142 of sender device 114. Subsequently, NIC 130 can send a transmission request 152 for transmitting data 134. Request 152 may include a descriptor for data 134. The descriptor may indicate the location of data 134, which may include the memory location of data 134 in memory device 132. When NIC 120 of receiver device 111 receives request 152, NIC 120 may allocate a location in receiver buffer 122 in the memory device of receiver device 111. Receiver buffer 122 may be allocated to sender buffer 132 (i.e., as a queue pair). Similarly, NIC 140 may send a transmission request 162 with a descriptor for data 144. The descriptor can indicate the memory location of data 144 in buffer 142.

[0037] When NIC 120 receives request 162, NIC 120 can allocate a location in receiver buffer 124. However, if request 162 arrives at NIC 120 before buffer 124 is allocated (e.g., as an unexpected request), processing of request 162 can be postponed until buffer 124 is allocated. Receiver buffer 124 can be allocated to sender buffer 142. In this way, NIC 120 can maintain multiple buffers 122, 124, 126, and 128, each for its corresponding sender buffer. NIC 120 can retrieve data 134 and 144 from the locations specified in the corresponding descriptors of requests 152 and 162, respectively. The retrieval process can bypass active application involvement. NIC 120 can use RDMA to retrieve data 134 and 144. For example, NIC 120 can use RDMA GET packets (e.g., datagrams) 154 and 164, respectively, to retrieve data from buffers 132 and 142. Because NIC 120 can pull data 134 and 144 from buffers 132 and 142 respectively, NIC 120 can control when data 134 and 144 arrive at receiving device 111. Here, NICs 120, 130, and 140 can use aggregation protocols supported by the HPC architecture. Aggregation protocols facilitate message-passing-based large data transfers. According to the aggregation protocol, the sending device can send a transmission request as a control signal to the receiving device. Upon receiving the transmission request, the receiving device can issue a read signal based on remote memory access, such as an RDMA GET message. The read signal can retrieve data from the sending device at the location indicated in the transmission request without involving the sending device's processor.

[0038] By acquiring data based on a schedule, NIC 120 can arrange how data 134 and 144 traverse network 110. This efficient acquisition-based incast management system can mitigate the impact of incast and reduce congestion in network 110. Furthermore, the acquisition process can be combined with a credit-based congestion management system. For example, if the congestion level or incast level reaches a threshold, the receiving device 111 can switch from a credit-based system to an acquisition-based system. The threshold can indicate one or more of the following: a predetermined number of sending devices, and a predetermined utilization level or percentage of the receiving buffer. On the other hand, if the congestion level reaches a high threshold (e.g., a high watermark), the receiving device 111 can suspend data acquisition for a predetermined period. Subsequently, when the period expires and the congestion level drops below the high threshold, the receiving device 111 can resume scheduling data acquisition.

[0039] Figure 1BAn example of out-of-order data acquisition according to one aspect of this application is illustrated. NIC 120 can also maintain tracking of successful data acquisition. The sender buffer 142 in NIC 140 can include data 174 and 176 for transmission to NIC 120. NIC 120 can allocate a predetermined position in buffer 124 for each of data 174 and 176. Therefore, the position in buffer 124 can indicate the order of data received from buffer 142. Based on the positions of data 174 and 176 in buffer 124, NIC 120 can determine whether data 174 and 176 arrived in order. Assume that NIC 120 uses RDMAGET packets 182 and 184 to acquire data 174 and 176 respectively. Packet 182 may be lost in network 110 (indicated by a cross). Therefore, NIC 120 may receive data 176 out of order.

[0040] However, position 180 in buffer 124 allocated for data 174 may remain unused. Therefore, NIC 120 can determine that data 176 is out of order. Data 176 can then be left in its position in buffer 124. NIC 120 can then retry retrieving data 174 from buffer 142. When NIC 120 receives data 174, it can determine that data 174 and 176 are stored in buffer 124 in order. NIC 120 can then push data 174 and 176 to the application. Thus, out-of-order data retrieval reduces the need for a reordering mechanism at receiving device 111.

[0041] Figure 2 A flowchart according to one aspect of this application is presented, illustrating an example of a NIC in a computing system using aggregation to implement congestion management. During operation, the NIC may receive a request from a remote computing system to send a piece of data via the network (operation 202). The NIC may determine that the request is from one of multiple requests from multiple remote computing systems accessible via the network (operation 204). Based on the descriptor in the request, the NIC may determine the storage location of a piece of data at the remote computing system (operation 206). The NIC may then determine the level of congestion associated with the multiple requests at the computing system (operation 208). Subsequently, the NIC may schedule data retrieval in response to the requests based on the level of congestion and relative to the multiple requests (operation 210). Accordingly, the NIC may retrieve the data from the storage location at the remote computing system based on remote access (operation 212).

[0042] Figure 3An example of receiver-driven incast-managed communication according to one aspect of this application is illustrated. HPC environment 300 may include network 310, which includes switches 322 and 324. In this example, nodes 350 and 360 of environment 300 may operate as a sender device and a receiver device, respectively. During operation, NIC 352 of sender device 350 may register a sender buffer 340 (e.g., located in a memory device of sender device 350) (operation 302). Buffer 340 may include a copy of data 342 that needs to be transmitted to receiver device 360. Upon receiving a request, NIC 352 may retrieve data 342 from the memory of sender device 350 (e.g., using a memcpy operation). NIC 352 may then send a transmission request to receiver device 360 ​​via locally coupled switch 324 (operation 304).

[0043] In some examples, NIC 352 may also add a "work completed" record to the completion queue associated with buffer 340. NIC 352 may optionally consider the transmission of data 342 complete, since NIC 362 can be responsible for retrieving data 342. Switch 322 may then forward the request to receiving device 360 ​​via network 310 (operation 306). The request may include a descriptor for data 342. Upon receiving the request, NIC 362 may determine the location of data 342. NIC 362 may also register receiving buffer 330 (e.g., located in the memory device of receiving device 360) as the corresponding buffer for buffer 340 (operation 308). NIC 362 may also allocate a location for data 342 in buffer 320 (operation 310). NIC 362 may use RDMA GET to retrieve data 342 from buffer 340 (operation 312). Here, NICs 362 and 352 may use a convergence protocol supported by the HPC architecture.

[0044] When NIC 362 receives data 342 (e.g., from an RDMA GET packet), NIC 362 can store data 342 in a location allocated in buffer 340 (operation 314). RDMA can be facilitated by network libraries instantiated on NICs 362 and 352. Examples of network libraries may include, but are not limited to, Message Passing Interface (MPI), Partition Global Address Space Library (e.g., OpenSHMEM), and Collective Communication Library (CCL) (e.g., NVIDIA© CCL or NCCL). NIC 362 can also send an acknowledgment indicating that NIC 362 has received data 342, which may include a short message (operation 316). Locally coupled switch 101 can receive the acknowledgment and forward it to sender device 350 via network 110 (operation 318). NIC 352 can then clear data 342 from buffer 340 (operation 320).

[0045] Figure 4A A flowchart according to one aspect of this application is presented, illustrating an example of a receiving device scheduling data acquisition in response to a transmission request. During operation, the receiving device may receive a transmission request for data from the sending device (operation 402). The transmission request may be a remote memory access request. The receiving device can then obtain a data descriptor from the request (operation 404). The descriptor may include the location of the data in the sending device's memory. The receiving device may then determine whether the request is an unexpected request (e.g., arriving before registering a local buffer for the data stream) (operation 406). If the request is unexpected, processing of the request may be postponed until a buffer is allocated (operation 414). The receiving device may then determine whether a receiving buffer has been allocated for the sending buffer (operation 416).

[0046] If no receiver buffer is allocated, processing of the request can continue to be postponed until a buffer is allocated (operation 414). If the request is not unexpected (operation 406) or occurs during receiver buffer allocation (operation 416), the receiver device can register the receiver buffer for the sender buffer (operation 408). In this way, data obtained from the sender buffer can be stored in the receiver buffer. The receiver device can then allocate a location for the data in the receiver buffer (operation 410). The receiver device can schedule the retrieval of data from the sender buffer based on the incast level (operation 412). In this way, the receiver device can schedule when to retrieve data based on the congestion level and relative to the number of sender devices requesting data retrieval. Based on scheduling, the receiver device can mitigate the effects of incast.

[0047] Figure 4BA flowchart according to one aspect of this application is presented, illustrating an example of a process by which a receiving device retrieves a copy of data from a sending device at a scheduled time. During operation, the receiving device can determine the location of the data based on the data descriptor (which can be obtained from the corresponding transmission request) (operation 452) and issue an RDMA GET to retrieve the data from the determined location (operation 454). The RDMA GET can retrieve the data from a memory device storing the data at the sending device. The receiving device can determine whether the retrieval was successful (operation 456). The RDMA GET process provides a mechanism by which the receiving device can determine successful retrieval.

[0048] If the acquisition fails, the receiving device can retry (operation 460) and continue issuing RDMAGET to acquire data (operation 454). Alternatively, if the acquisition is successful, the receiving device can store the acquired data in a pre-selected location in the receive buffer (operation 458). Since the data acquisition location is pre-selected, the acquisition can be out of order and independent of sequence numbers. In this way, if the receiving device maintains the order of request transmission operations (e.g., by using a sorting scheme), data can be acquired and transmitted to the receiving device's memory in any order.

[0049] Figure 5 A flowchart according to one aspect of this application is presented, illustrating an example of a process in which a sending device sends a transmission request to a receiving device. During operation, the sending device may obtain data for transmission (operation 502) (e.g., from a distributed application). The sending device may store the data in a sending buffer (operation 504). The sending buffer may be located in the sending device's memory device. The sending device may then determine a descriptor indicating the location of the data in the sending buffer (operation 506). The sending device may then generate a transmission request with the descriptor (operation 508) and send the transmission request to the receiving device (operation 510). Here, the transmission request may be an RDMA request.

[0050] Figure 6An example of a computing system according to one aspect of this application that facilitates receiver-driven incast management using data acquisition is illustrated. The computing system 600 may include a set of processors 602, a memory unit 604, a NIC 606, and a storage device 608. The memory unit 604 may include a set of volatile memory devices (e.g., dual in-line memory modules (DIMMs)). Furthermore, if desired, the computing system 600 may be coupled to a display device 612, a keyboard 614, and a pointing device 616. The storage device 608 may store an operating system 618. An incast management system 620 and data 636 associated with the incast management system 620 may be maintained and executed from the storage device 608 and / or the NIC 606.

[0051] The incast management system 620 may include instructions that, when executed by the computing system 600, cause the computing system 600 to perform the methods and / or processes described in this disclosure. Specifically, if the computing system 600 is a sending device, the incast management system 620 may include instructions (request logic block 622) for sending a transmission request for a copy of data with a descriptor to a receiving device. The incast management system 620 may also include instructions (buffer logic block 628) for storing data in a sending buffer (e.g., in the NIC 606).

[0052] On the other hand, if the computing system 600 is a receiving device, the incast management system 620 may include instructions for receiving a transmission request and obtaining a descriptor from the request (request logic block 622). The incast management system 620 may also include instructions for scheduling the retrieval of data from the sending device based on a level of congestion as indicated by the incast level (scheduling logic block 624). The incast level may depend on the number of sending devices. Furthermore, the incast management system 620 may include instructions for remotely retrieving a copy of data from a location indicated in the descriptor included in the request (e.g., using RDMA) (retrieval logic block 626).

[0053] The incast management system 620 may further include instructions (buffer logic block 628) for allocating positions for data in the receiver buffer. Additionally, the incast management system 620 may include instructions (buffer logic block 628) for storing acquired data in the allocated positions. The incast management system 620 may also include instructions (sequence logic block 630) for determining whether data was acquired in sequence. Furthermore, the incast management system 620 may also include instructions (sequence logic block 630) for pushing data that has been acquired in sequence.

[0054] The incast management system 620 may further include instructions (communication logic block 632) for sending and receiving packets. Data 636 may include any data that facilitates the operation of the incast management system 620. Data 636 may include, but is not limited to, descriptors, data to be transmitted, out-of-order data, and completion records.

[0055] Figure 7 An example of a non-transitory computer-readable storage device according to one aspect of this application, which facilitates receiver-driven incast management using data acquisition, is illustrated. The computer-readable storage device 700 may include multiple units or devices that can communicate with each other via wired, wireless, quantum, optical, or electrical communication channels. The storage device 700 may be implemented using one or more integrated circuits and may include more than Figure 7 The unit or device shown may be fewer or more units or devices.

[0056] Furthermore, the memory device 700 can be integrated with a computer system. For example, the memory device 700 can reside in the computer system's NIC. The memory device 700 can include functions that perform operations related to... Figure 6 The logic blocks 622-632 of the incast management system 620 have similar functions or operations to the units 702-712, including: request unit 702; scheduling unit 704; acquisition unit 706; storage unit 708; sequence unit 710; and communication unit 712.

[0057] The description herein is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed examples will be apparent to those skilled in the art, and the general principles defined herein can be applied to other examples and applications without departing from the spirit and scope of the invention. Therefore, the invention is not limited to the examples shown, but is intended to be accorded the maximum scope consistent with the claims.

[0058] One aspect of this technology provides a NIC that facilitates efficient incast management at a computing system. During operation, the NIC can receive requests to send data from remote computing systems via a network. The NIC can determine that the request is one of multiple requests from multiple remote computing systems accessible via the network. Based on the descriptor in the request, the NIC can determine the storage location of the data at the remote computing system. The NIC can then determine the level of congestion at the computing system associated with the multiple requests. Subsequently, the NIC can schedule data retrieval in response to the requests based on the congestion level and relative to the multiple requests. The NIC can then retrieve the data from the storage location at the remote computing system based on remote access.

[0059] In a variation of this approach, to schedule data acquisition, the NIC can determine whether the congestion level exceeds a predetermined threshold indicating the number of computing systems sending data to the computing system. If the congestion level exceeds the threshold, the NIC can suspend scheduling for a predetermined period.

[0060] In this variation, the data is stored in the sender's buffer of the remote computing system.

[0061] In this variation, the NIC can determine the location for storing data in the receiver buffer at the computing system. The NIC can then store the data in the determined location.

[0062] In further variations, data can be obtained without relying on serial numbers.

[0063] In this variation, the computing system can be a receiving device. A remote computing system can be a sending device.

[0064] In this variation, remote access can be based on remote direct memory access (RDMA) from the NIC.

[0065] In a variation of this approach, the network may include a high-performance computing (HPC) architecture that supports data retrieval. Here, data retrieval may be based on a convergence protocol supported by the HPC architecture. The convergence protocol may support sending data transfer requests and retrieving data via remote access.

[0066] In this variation, the degree of congestion is determined based on the incast level caused by multiple remote computing systems at the computing system.

[0067] The data structures and code described in this specific embodiment are typically stored on a computer-readable storage medium, which can be any device or medium capable of storing code and / or data for use by a computer system. Computer-readable storage media include, but are not limited to, volatile memory, non-volatile memory, magnetic storage devices and optical storage devices (such as magnetic disks, magnetic tapes, CDs (compact discs), DVDs (digital versatile discs or digital video discs)), or other media capable of storing computer-readable media now known or developed in the future.

[0068] The methods and processes described in the Detailed Description section can be embodied in code and / or data, which can be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system executes the methods and processes embodied in data structures and code and stored in the computer-readable storage medium.

[0069] The methods and processes described herein may be executed by and / or included therein by hardware logic blocks or devices. These logic blocks or devices may include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), dedicated or shared processors that execute specific software logic blocks or a set of code at a specific time, and / or other programmable logic devices now known or later developed. When the hardware logic blocks or devices are activated, they execute the methods and processes included therein.

[0070] The preceding description of examples of the invention is presented for illustrative and descriptive purposes only. The description is not intended to be exhaustive or limiting of this disclosure. Accordingly, many modifications and variations will be apparent to those skilled in the art. The scope of the invention is defined by the appended claims.

Claims

1. A computing system, comprising: Memory devices; as well as Network Interface Controller (NIC) is used for: A first request to send the first data to a remote computing system storing the first data is received via a network, wherein the network includes a high-performance computing (HPC) architecture that supports the retrieval of the first data based on a convergence protocol supported by the HPC architecture, and wherein the convergence protocol supports sending the first request for the first data and the retrieval of the first data based on remote memory access; the first request is determined to be one of a plurality of requests to send data to a plurality of remote computing systems accessible via the network. The storage location of the first piece of data at the remote computing system is determined based on the descriptor in the first request; The number of the plurality of requests is determined as the incast level at the computing system; Based on the incast level and relative to the plurality of requests, schedule the time for retrieving the first data in response to the first request; and The first data is retrieved from the storage location at the remote computing system at the scheduled time based on the convergence protocol.

2. The computing system as claimed in claim 1, wherein, In order to schedule the acquisition of the first piece of data, the NIC is used for: Determine whether the incast level is greater than a predetermined threshold indicating the number of computing systems sending data to the computing system; and In response to the incast level being greater than the threshold, the scheduling will be suspended for a predetermined period of time.

3. The computing system as described in claim 1, wherein, The storage location of the first data at the remote computing system is located in the sender buffer of the remote computing system.

4. The computing system as claimed in claim 1, wherein, The NIC is further used for: Before obtaining the first data, determine the location in the receiver buffer at the computing system for storing the first data; and In response to obtaining the first piece of data, the first piece of data is stored at the determined location.

5. The computing system as described in claim 1, wherein, The first data is obtained without relying on the sequence number.

6. The computing system as claimed in claim 1, wherein, The computing system is the receiving device of the remote memory access, and the remote computing system is the sending device of the remote memory access.

7. The computing system as claimed in claim 1, wherein, The remote memory access is based on Remote Direct Memory Access (RDMA) from the computing system.

8. A method for data transmission, comprising: A receiving device receives a first request to send the first data to the receiving device via a network from an application running on the sending device storing the first data, wherein the network includes a high-performance computing (HPC) architecture that supports the retrieval of the first data based on a convergence protocol supported by the HPC architecture, and wherein the convergence protocol supports sending the first request for the first data and the retrieval of the first data based on remote memory access. The first request is determined to be one of a plurality of requests to send data to the receiving device, which are received from a plurality of sending devices that can be accessed via the network. The storage location of the first data at the sending device is determined based on the descriptor in the first request; The number of the multiple requests is determined as the incast level at the receiving device; The receiving device schedules the acquisition time of the first data in response to the first request based on the incast level and relative to the plurality of requests; and The receiving device retrieves the first data from the storage location at the sending device at a scheduled time based on the convergence protocol.

9. The method of claim 8, wherein, The scheduling of obtaining the first piece of data includes: Determine whether the incast level is greater than a predetermined threshold indicating the number of computing systems sending data to the computing system; and In response to the incast level being greater than the threshold, the scheduling will be suspended for a predetermined period of time.

10. The method of claim 8, wherein, The first data is stored in a sender buffer within a memory device of the sender device, and the first request is generated at the network interface controller (NIC) of the sender device.

11. The method of claim 8, further comprising: Before obtaining the first data, determine the location in the receiver buffer at the receiver device for storing the first data; as well as In response to obtaining the first piece of data, the first piece of data is stored at the determined location.

12. The method of claim 8, wherein, The first data is obtained without relying on the sequence number.

13. The method of claim 8, wherein, The timing of the acquisition of the first data and the acquisition of the first data are performed by the NIC of the receiving device.

14. The method of claim 8, wherein, The remote memory access is based on Remote Direct Memory Access (RDMA) from the receiving device.

15. A non-transitory computer-readable storage medium, comprising instructions that, when executed on a network interface controller (NIC) of a receiving device in a distributed system, cause the NIC to: A first request is received via a network from a sending device storing the first data, requesting that the first data be sent to the receiving device. The network includes a high-performance computing (HPC) architecture that supports the acquisition of the first data based on a convergence protocol supported by the HPC architecture, wherein the convergence protocol supports sending the first request for the first data and the acquisition of the first data based on remote memory access. The first request is determined to be one of a plurality of requests to send data to the receiving device, received from a plurality of sending devices accessible via the network; and The storage location of the first data at the sending device is determined based on the descriptor in the first request; The number of the multiple requests is determined as the incast level at the receiving device; Based on the incast level and relative to the plurality of requests, the time for obtaining the first data in response to the first request is scheduled; and based on the convergence protocol, the first data is obtained from the storage location at the sending device to the NIC at the scheduled time.

16. The non-transitory computer-readable storage medium of claim 15, wherein, When the instruction is executed on the NIC, the NIC: Before obtaining the first data, determine the location for storing the first data in the receiver buffer at the receiver device; and In response to obtaining the first piece of data, the first piece of data is stored at the determined location.

17. The non-transitory computer-readable storage medium of claim 15, wherein, The storage location of the first data at the sending device is located in the sending buffer of the sending device's memory device, and the first request is generated at the second NIC of the sending device.

18. The non-transitory computer-readable storage medium of claim 15, wherein, The NIC schedules the acquisition of the first data in the following manner: Determine whether the incast level is greater than a predetermined threshold indicating the number of computing systems sending data to the computing system; and In response to the incast level being greater than the threshold, the scheduling will be suspended for a predetermined period of time.

Images