阅读说明：本技术 在网络接口控制器(nic)中促进对幂等操作进行高效管理的系统和方法 (System and method for facilitating efficient management of idempotent operations in a Network Interface Controller (NIC) ) 是由 D·罗威斯 R·L·阿尔弗森 A·成 T·J·约翰逊 于 2020-03-23 设计创作，主要内容包括：提供了一种能够促进对幂等操作进行高效管理的网络接口控制器(NIC)。所述NIC可以配备有网络接口和操作管理逻辑块。在操作期间,所述网络接口可以接收来自远程设备的操作请求。所述操作管理逻辑块可以确定所述请求是否是针对幂等操作。如果所述请求是针对幂等操作,则所述操作管理逻辑块可以执行所述操作以生成输出结果并生成包括所述输出结果的响应来对所述请求作出响应。(A Network Interface Controller (NIC) is provided that facilitates efficient management of idempotent operations. The NIC may be equipped with a network interface and operation management logic. During operation, the network interface may receive an operation request from a remote device. The operation management logic block may determine whether the request is for an idempotent operation. If the request is for an idempotent operation, the operation management logic may perform the operation to generate an output result and generate a response including the output result to respond to the request.)

1. A Network Interface Controller (NIC), comprising:

a network interface for receiving an operation request from a remote device; and

an operations management logic block to:

determining whether the request is for an idempotent operation;

in response to determining that the request is for an idempotent operation:

performing the operation to generate an output result; and

generating a response to respond to the request that includes the output result.

2. The network interface controller of claim 1, wherein the request is a multi-packet request, wherein the request is distributed among a plurality of packets, and wherein the packets are among the plurality of packets.

3. The network interface controller of claim 2, wherein a respective packet of the plurality of packets includes an operation corresponding to the request, thereby rendering the packet as a single packet request.

4. The network interface controller of claim 1, wherein the operation management logic block is further to perform the operation to generate the output result without checking whether the operation has been previously performed by the network interface controller.

5. The network interface controller of claim 4, wherein the packet is sent from a retry buffer of the remote device.

6. The network interface controller of claim 1, wherein the operations management logic is further to perform the operations based on a memory access via a peripheral component interconnect express (PCIe) interface of the network interface controller.

7. The network interface controller of claim 1, wherein the operation corresponds to a Remote Direct Memory Access (RDMA) command.

8. A method, comprising:

receiving, by a Network Interface Controller (NIC), an operation request from a remote device;

determining whether the request is for an idempotent operation;

in response to determining that the request is for an idempotent operation, performing the operation to generate an output result; and

generating a response to respond to the request that includes the obtained output result.

9. The method of claim 8, wherein the request is a multi-packet request, wherein the request is distributed among a plurality of packets, and wherein the packets are among the plurality of packets.

10. The method of claim 9, wherein a respective package of the plurality of packages includes an operation corresponding to the request, thereby rendering the package as a single package request.

11. The method of claim 8, further comprising performing the operation to generate the output result without checking whether the NIC has previously performed the operation.

12. The method of claim 8, wherein the packet is transmitted from a retry buffer of the remote device.

13. The method of claim 8, wherein the operation management logic is further to perform the operation based on a memory access via a peripheral component interconnect express (PCIe) interface of the network interface controller.

14. The method of claim 8, wherein the operation corresponds to a Remote Direct Memory Access (RDMA) command.

15. A computer system, comprising:

a processor;

a Network Interface Controller (NIC); and

a host interface to couple to the NIC;

wherein the NIC comprises:

a network interface for receiving an operation request from a remote device; and an operations management logic block to:

determining whether the request is for an idempotent operation; and

in response to determining that the request is for an idempotent operation:

performing the operation to generate an output result; and

generating a response to respond to the request that includes the output result.

16. The computer system of claim 15, wherein the request is a multi-packet request, wherein the request is distributed among a plurality of packets, and wherein the packets are among the plurality of packets.

17. The computer system of claim 16, wherein a respective package of the plurality of packages includes an operation corresponding to the request, thereby rendering the package as a single package request.

18. The computer system of claim 15, wherein the operation management logic block is further to perform the operation to generate the output result without checking whether the network interface controller has previously performed the operation.

19. The computer system of claim 15, wherein the operations management logic is further to perform the operations based on a memory access via a peripheral component interconnect express (PCIe) interface of the network interface controller.

20. The computer system of claim 15, wherein the operation corresponds to a Remote Direct Memory Access (RDMA) command.

Technical Field

The present disclosure relates generally to the field of networking technology. More particularly, the present disclosure relates to systems and methods for facilitating efficient management of idempotent operations by a Network Interface Controller (NIC).

Prior Art

As network-enabled devices and applications become more prevalent, various types of traffic and increasing network loads continue to demand higher performance from the underlying network architecture. For example, applications such as High Performance Computing (HPC), streaming media, and internet of things (IOT) may produce different types of traffic that are well characterized. Thus, in addition to traditional network performance metrics such as bandwidth and latency, network architects continue to face challenges such as scalability, versatility, and efficiency.

Background

Disclosure of Invention

A Network Interface Controller (NIC) capable of efficiently managing idempotent operations is provided. The NIC may be equipped with a network interface and operation management logic. During operation, the network interface may receive an operation request from a remote device. The operation management logic block may determine whether the request is for an idempotent operation. If the request is for an idempotent operation, the operation management logic may perform the operation to generate an output result and generate a response including the output result to respond to the request.

Drawings

Fig. 1 illustrates an exemplary network.

Fig. 2A shows an exemplary NIC chip having multiple NICs.

Fig. 2B shows an exemplary architecture of a NIC.

Fig. 3A illustrates an exemplary dynamic management process for idempotent operations in a NIC.

Fig. 3B illustrates an exemplary dynamic management process for idempotent operation in a NIC.

Fig. 4A shows a flow diagram of a dynamic management process for idempotent operations in an originating NIC.

Fig. 4B illustrates a flow diagram of a dynamic management process for idempotent operations in a target NIC.

Fig. 5 illustrates an example computer system equipped with a NIC that facilitates dynamic management of idempotent operations.

In the drawings, like reference numerals refer to like elements.

Detailed Description

Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. The invention is thus not limited to the embodiments shown.

SUMMARY

This disclosure describes systems and methods that facilitate dynamic management of idempotent operations in a Network Interface Controller (NIC). The NIC allows the host to communicate with a data driven network. The network can adapt to dynamic data traffic by maintaining state information for individual packet flows for fast, efficient congestion control. More specifically, packets injected into the switch network may be classified into flows, which may be mapped to their layer 2, layer 3, or other protocol specific header information. Each flow may be tagged with a different identifier local to the input port of the switch and provided with a flow specific input buffer so that each flow can be individually flow controlled. In addition, packets in the respective streams may be acknowledged upon reaching an exit point of the network, and the acknowledged packets may be sent back to the entry point of the stream in the opposite direction along the same data path. Thus, each switch can obtain state information for the active packet flows it is forwarding and can perform highly responsive, flow-specific flow control. Such flow control may allow the network to operate at higher capacity while providing general traffic engineering capabilities.

Embodiments described herein address the problem of ensuring that idempotent operations of remote requests are properly performed by: (i) performing a single packet operation without tracking whether the operation is a repeat operation; and (ii) a memory location to store an output result of the multi-packet operation. In this way, the NIC may respond to the repeat request with the memory location of the output result of the multi-packet operation that has been performed.

During operation, an application that may be running on a source device of the NIC may request a data operation (e.g., a Remote Direct Memory Access (RDMA) "GET" or "PUT" command) on a memory location of a remote target device. The NIC of the target device may receive the request, facilitate performance of the operation, and send a response with the performance output. Examples of output results may include, but are not limited to: one or more values generated from calculations associated with the operation; an indicator indicating successful or unsuccessful execution of the operation; a memory location or index associated with the operation; and information indicating a state of the data structure based on performing the operation on the data structure. The NICs of the source device and the destination device may be referred to as a source NIC and a destination NIC, respectively. The operations may be idempotent operations or non-idempotent operations. Idempotent operations can be performed more than once without causing errors. On the other hand, a non-idempotent operation may be performed once. Performing a non-idempotent operation more than once may result in errors.

In general, if an idempotent RDMA operation is not completed, the target device's software (e.g., operating system) may replay the operation, rather than the target NIC performing the operation. However, such software-based execution may consume a significant amount of host bandwidth (e.g., bandwidth of the internal bus) and processor cycles. Furthermore, the computational overhead incurred by tracing the completion of an operation may be higher than the computational overhead of the computational load of the operation. Thus, tracking idempotent operations may be inefficient.

To address this issue, the originating NIC may generate an indicator that indicates whether the requested operation is an idempotent operation or a non-idempotent operation. The originating NIC may then include the request in a packet and send the packet to the destination NIC via the switch fabric. The originating NIC may include the indicator in the request (e.g., as a parameter of the request) or in the packet (e.g., in a header of the packet). Upon receiving the request, the target NIC may determine that the requested operation is an idempotent operation based on the indicator. The target NIC may then perform the operation without determining whether the operation is a duplicate operation and generate an output result (or results) of the operation. The target NIC may perform operations based on memory accesses via a peripheral component interconnect express (PCIe) interface of the target NIC. The destination NIC may then include the output result in a response packet and send the response back to the source NIC. This allows the target NIC to avoid tracking the completion status of idempotent operations.

A request for an idempotent operation may generate a set of operations if the request is associated with a large number of memory locations. Each operation in the set of operations may correspond to an idempotent operation. The originating NIC may generate a plurality of packets for the request (one for each operation in the set of operations) and send the corresponding packets to the destination NIC. Such a request may be referred to as a multi-packet request. Because each packet may include a corresponding operation, multi-packet requests for idempotent operations may be transmitted as a set of single packet requests. The originating NIC may store the corresponding data packet of the request in a retry buffer. If the originating NIC does not receive a response to the packet within the time out interval, the originating NIC may retrieve the packet from the retry buffer and retransmit the packet.

For each packet, the destination NIC may perform the operation without determining whether the operation is a duplicate operation and generate an output result (or results) of the operation. The destination NIC may then include the output result in a response packet and send the response back to the source NIC. Because the operations are idempotent operations and are distributed among multiple packets in such a way that each packet may represent a single packet idempotent operation, the destination NIC may not store the output results of the operations associated with each individual packet.

One embodiment of the present invention provides a NIC that may be equipped with a network interface and operation management logic. During operation, the network interface may receive an operation request from a remote device. The operation management logic block may determine whether the request is for an idempotent operation. If the request is for an idempotent operation, the operation management logic may perform the operation to generate an output result and generate a response including the output result to respond to the request.

In a variation of this embodiment, the request may be a multi-packet request. The request may then be distributed among multiple packets. Thus, the packet may be in the plurality of packets.

In a further variation, a respective package of the plurality of packages includes an operation corresponding to the request, thereby rendering the package as a single package request.

In a variation of this embodiment, the operation management logic may perform the operation to generate the output result without checking whether the NIC has previously performed the operation.

In a variation of this embodiment, the packet is sent from a retry buffer of the remote device.

In a variation of this embodiment, the operation management logic may perform the operation based on a memory access via a peripheral component interconnect express (PCIe) interface of the NIC.

In a variation of this embodiment, the operation corresponds to an RDMA command.

In this disclosure, the description in connection with fig. 1 is related to network architecture, and the description in connection with fig. 2A and beyond provides more details regarding the architecture and operation associated with NICs that support efficient management of idempotent operations.

Fig. 1 illustrates an exemplary network. In this example, switch network 100 (which may also be referred to as a "switch fabric") may include switches 102, 104, 106, 108, and 110. Each switch may have a unique address or ID within the switch fabric 100. Various types of devices and networks may be coupled to the switch fabric. For example, storage array 112 may be coupled to switch fabric 100 via switch 110; infiniband (IB) -based HPC network 114 may be coupled to switch fabric 100 via switch 108; a plurality of end hosts, such as host 116, may be coupled to the switch fabric 100 via the switch 104; and the IP/ethernet network 118 may be coupled to the switch fabric 100 via the switch 102. In general, a switch may have edge ports and fabric ports. The edge port may be coupled to a device external to the structure. The fabric port may be coupled to another switch within the fabric via a fabric link. In general, traffic may be injected into the switch fabric 100 via an ingress port of an edge switch and exit the switch fabric 100 via an egress port of another (or the same) edge switch. An ingress link may couple a NIC of an edge device (e.g., HPC end host) to an ingress edge port of an edge switch. The switch fabric 100 may then transmit the traffic to an egress edge switch, which in turn may transmit the traffic to a destination edge device via another NIC.

Exemplary NIC architecture

Fig. 2A shows an exemplary NIC chip having multiple NICs. Referring to the example in fig. 1, NIC chip 200 may be a custom Application Specific Integrated Circuit (ASIC) designed for host 116 to work with switch fabric 100. In this example, chip 200 may provide two separate NICs 202 and 204. Each NIC of chip 200 may be equipped with a Host Interface (HI) (e.g., an interface for connecting to a host processor) and a high-speed network interface (HNI) for communicating with links coupled to switch fabric 100 of fig. 1. For example, the NIC 202 may include the HI 210 and the HNI 220, and the NIC 204 may include the HI 211 and the HNI 221.

In some embodiments, the HI 210 may be a Peripheral Component Interconnect (PCI) interface or a peripheral component interconnect express (PCIe) interface. The HI 210 may be coupled to a host via a host connection 201, which may include N (e.g., N may be 16 in some chips) PCIe Gen 4 lanes capable of operating at signaling rates up to 25Gbps per lane. The HNI 210 may facilitate a high-speed network connection 203 that may communicate with links in the switch fabric 100 of fig. 1. The HNI 210 may operate at a total rate of 100Gbps or 200Gbps using M (e.g., M may be 4 in some chips) full-duplex serial lanes. Each of the M channels may operate at 25Gbps or 50Gbps based on non return to zero (NRZ) modulation or pulse amplitude modulation 4(PAM4), respectively. The HNI 220 may support Institute of Electrical and Electronics Engineers (IEEE)802.3 ethernet-based protocols, as well as enhanced frame formats that provide support for higher rate small messages.

The NIC 202 may support one or more of the following: message Passing Interface (MPI) based point-to-point messaging, Remote Memory Access (RMA) operations, offloading and scheduling of bulk data collective operations, and ethernet packet processing. When the host issues an MPI message, the NIC 202 may match the corresponding message type. Further, the NIC 202 may implement both the urgency protocol and the agreement protocol for MPI, thereby offloading corresponding operations from the host.

Further, RMA operations supported by the NIC 202 may include PUT, GET, and Atomic Memory Operations (AMO). The NIC 202 may provide reliable transmissions. For example, if the NIC 202 is an originating NIC, the NIC 202 may provide a retry mechanism for idempotent operations. Furthermore, connection-based error detection and retry mechanisms may be used for ordered operations that may manipulate the target state. The hardware of NIC 202 may maintain the state required for the retry mechanism. In this way, the NIC 202 may relieve the burden on the host (e.g., software). The policy for deciding the retry mechanism may be specified by the host through driver software to ensure flexibility of the NIC 202.

In addition, the NIC 202 may facilitate the scheduling of trigger operations, generic offload mechanisms, and dependent sequences of operations (such as bulk data sets). NIC 202 may support an Application Programming Interface (API), such as a libfabric API, to facilitate the provision of fabric communication services by switch fabric 100 of fig. 1 to applications running on host 116. The NIC 202 may also support a low-level network programming interface, such as a Portals API. Additionally, the NIC 202 may provide efficient ethernet packet processing that may include efficient transmission when the NIC 202 is the sender, flow manipulation when the NIC 202 is the target, and checksum calculation. Further, the NIC 202 may support virtualization (e.g., using a container or virtual machine).

Fig. 2B shows an exemplary architecture of a NIC. In the NIC 202, the port macro of the HNI 220 may facilitate low-level ethernet operations, such as Physical Coding Sublayer (PCS) and Media Access Control (MAC). Additionally, the NIC 202 may provide support for Link Layer Retry (LLR). The incoming packets may be parsed by the parser 228 and stored in the buffer 229. The buffer 229 may be a PFC buffer supplied to buffer a threshold amount (e.g., one microsecond) of delay bandwidth. HNI 220 may also include a control transmit unit 224 and a control receive unit 226 for managing outgoing and incoming packets, respectively.

NIC 202 may include a Command Queue (CQ) unit 230. CQ unit 230 may be responsible for fetching and issuing host-side commands. CQ unit 230 may include a command queue 232 and a scheduler 234. The command queue 232 may include two separate sets of queues for initiator commands (PUT, GET, etc.) and target commands (appendix, Search, etc.), respectively. The command queue 232 may be implemented as a circular buffer maintained in memory of the NIC 202. An application running on the host may write directly to the command queue 232. The scheduler 234 may include two separate schedulers for initiator commands and target commands, respectively. The initiator commands are sorted into the flow queue 236 based on a hash function. One of the flow queues 236 may be assigned to a unique flow. In addition, CQ unit 230 may further include a trigger action module 238, which is responsible for queuing and dispatching trigger commands.

The outbound transport engine (OXE)240 may pull the command from the flow queue 236 to process it for dispatch. OXE 240 may include an Address Translation Request Unit (ATRU)244, which may send an address translation request to Address Translation Unit (ATU) 212. ATU 212 may provide virtual to physical address translation on behalf of different engines, such as OXE 240, inbound transport engine (IXE)250, and Event Engine (EE) 216. ATU 212 may maintain a large translation cache 214. ATU 212 may perform the translation itself or may use a host-based Address Translation Service (ATS). OXE 240 may also include a message slicing unit (MCU)246 that may slice a large message into packets of a size corresponding to a Maximum Transmission Unit (MTU). MCU 246 may include a plurality of MCU modules. When the MCU module is available, the MCU module can obtain the next command from the assigned stream queue. The received data may be written into the data buffer 242. The MCU module can then send the packet header, the corresponding traffic classification, and the packet size to the traffic shaper 248. Shaper 248 may determine which requests made by MCU 246 may enter the network.

The selected packets may then be sent to a Packet and Connection Tracking (PCT) 270. The PCT 270 may store the packet in the queue 274. The PCT 270 may also maintain status information for outbound commands and update the status information when responses are returned. PCT 270 may also maintain packet status information (e.g., to allow matching of responses to requests), message status information (e.g., to track progress of multi-packet messages), initiator completion status information, and retry status information (e.g., to maintain information needed to retry a command if a request or response is lost). If no response is returned within the threshold time, the corresponding command may be stored in retry buffer 272. The PCT 270 may facilitate connection management for initiator commands and target commands based on the source table 276 and the target table 278, respectively. For example, the PCT 270 may update its source table 276 to track the status required to reliably deliver packets and message completion notifications. PCT 270 may forward the outgoing packet to HNI 220, which stores the packet in outbound queue 222.

The NIC 202 may also include an IXE 250 that provides packet processing when the NIC 202 is the target or destination. The IXE 250 may obtain the incoming packets from the HNI 220. The parser 256 may parse incoming packets and pass corresponding packet information to a List Processing Engine (LPE)264 or a Message State Table (MST)266 for matching. LPE 264 may match incoming messages to buffers. LPE 264 may determine the buffer and starting address to be used for each message. LPE 264 may also manage a pool of list entries 262 representing buffers, as well as exception messages. MST 266 may store the matching results and the information needed to generate the target end completion event. MST 266 may be used by unlimited operations, including multi-packet PUT commands and single-packet and multi-packet GET commands.

The parser 256 may then store the packet in the packet buffer 254. The IXE 250 may obtain the matching result for conflict checking. The DMA write and AMO module 252 may then issue the updates generated by the write and AMO operations to the memory. If a packet includes a command (e.g., a GET response) that generates a target-side memory read operation, the packet may be passed to OXE 240. The NIC 202 may also include an EE 216 that may receive requests to generate event notifications from other modules or units in the NIC 202. The event notification may specify that a fill event or a count event is generated. EE 216 may manage an event queue located within the host processor memory that writes complete events to the host processor memory. EE 216 may forward the counting event to CQ unit 230.

Dynamic operation management in NICs

Fig. 3A illustrates an exemplary dynamic management process for non-idempotent operations in a NIC. In this example, devices 302 and 304 may be coupled to each other via a switch fabric 310. Devices 302 and 304 may be equipped with NICs 320 and 330, respectively. HNIs 322 and 332 may couple NICs 320 and 330, respectively, to switch fabric 310. During operation, an application 304 running on the device 302 may issue a request 312 to perform a data operation 342 (e.g., an RDMA operation) on a memory location of the device 304. Since device 302 is the source and device 304 is the target of request 312, devices 302 and 304 may be referred to as the source and target devices of request 312, respectively.

NIC 330 may receive request 312, facilitate performance of operation 342, and send response 314 with the results of the performance output of operation 342. Examples of output results may include, but are not limited to: one or more values generated from the calculations associated with operation 342; an indicator indicating success or failure of execution of operation 342; the memory location or index associated with operation 342; and information indicating the state of the data structure based on performing operation 342 on the data structure.

Assume operation 342 is an idempotent operation. Since the request 312 may originate from the NIC 320 and travel across the switch fabric 310 to the NIC 330, the operation 342 is performed based on a request-response communication protocol between the NICs 320 and 330. The PCT 324 and 334 may facilitate tracking packets for the NICs 320 and 330, respectively, to support communication protocols. In this case, if device 320 issues request 312 but does not receive response 314, then either request 312 or response 314 may be lost (e.g., due to a packet loss occurring in switch fabric 310). Such a loss may result in the PCT 324 determining that an operation has not been performed. Thus, to perform an operation, the PCT 324 can reissue the request 312.

The NIC 320 may not be able to distinguish between a request 312 or a response 314 that was missed. Thus, the NIC 320 may not be able to determine whether the operation 342 has already been performed by the NIC 330. Therefore, even though the NIC 330 has performed the operation 342, the NIC 320 may reissue the request 312 for the operation 342. Thus, upon receiving reissued request 312, the software of device 304 may replay operation 342. However, such software-based execution may consume a significant amount of resources of the device 304, such as computing resources and internal bandwidth. Furthermore, the computational overhead incurred to track the completion of operation 342 may be higher than the computational load of operation 342. Thus, tracking the state of operation 342 may be inefficient.

To address this issue, the NIC 320 may generate an indicator that indicates whether the operation 342 is an idempotent operation. The NIC 320 may then include the request 312 in a packet and send the packet to the NIC 330 via the switch fabric 310. The NIC 320 may include an indicator in the request 314 or packet. Upon receiving the request 312, the NIC 330 may determine that the operation 342 is an idempotent operation based on the indicator. The NIC 330 may then perform the operation 342 without determining whether the operation is a repeat operation and generate the output result 344. The NIC 330 may then include the output result 344 in the response 314, include the response 314 in a packet, and send the response to the NIC 320. This allows the NIC 330 to avoid tracking the state of the operation 342.

Fig. 3B illustrates an exemplary dynamic management process for idempotent operation in a NIC. If a request 350 for an idempotent operation is associated with a large number of memory locations, the request 350 may generate a set of operations. Each of these operations may correspond to an idempotent operation of request 350. Accordingly, the NIC 320 may generate a plurality of packets associated with the request 350, such as packets 352 and 352, each for one of the set of operations. The NIC 320 may then send the respective packets 352 and 354 to the NIC 330. Request 350 may be referred to herein as a multi-packet request (e.g., a multi-packet GET request that causes a memory read operation). In addition, the PCT 324 can store the packets 352 and 354 in the retry buffer 326 in the PCT 324. If the NIC 320 does not receive a response to a packet, such as the packet 354, within the timeout interval, the NIC 320 may obtain the packet 354 from the retry buffer 326 and resend the packet 354 to the NIC 330. The PCT 324 may remove packets from the retry buffer upon receiving corresponding response packets.

For each of the packets 352 and 354, the NIC 330 may perform the operation without determining whether the operation is a duplicate operation and generate an output result (or results) of the operation. The NIC 330 may perform operations based on memory accesses to the memory of the device 304 via the HI of the NIC 330. NIC 330 may then include the corresponding output results in response packets 382 and 384, respectively. The NIC 330 then sends the response packets 382 and 384 back to the NIC 320. Since the operations are idempotent operations and are distributed among the packets 352 and 354 in such a way that each packet may represent a single packet idempotent operation associated with the request 350, the NIC 330 may not store the output results of the operations associated with each individual packet.

Fig. 4A shows a flow diagram of a dynamic management process for idempotent operations in an originating NIC. During operation, the NIC may receive a request for an idempotent operation (e.g., a stream queue or retry buffer from the NIC) (operation 402) and check whether the request is a multi-packet request (operation 404). If the request is not a multi-packet request, the NIC may generate a packet with the operation request (operation 412) and send the packet to the destination NIC (operation 414). On the other hand, if the request is a multi-packet request, the NIC may generate a set of operations corresponding to idempotent operations (operation 406). The NIC may then generate a set of packets with requests for individual operations in the set of operations (operation 408). The NIC may then send the set of packets to the destination NIC (operation 410).

Fig. 4B illustrates a flow diagram of a dynamic management process for idempotent operations in a target NIC. During operation, the NIC may obtain a request for an idempotent operation from a packet received from a remote NIC (operation 452) and perform the operation to obtain an output result without checking whether the operation is a duplicate operation (i.e., without checking whether the operation is reissued from the remote NIC) (operation 454). The NIC may then include the output result in a packet and forward the packet to the remote NIC (operation 456).

Exemplary computer System

Fig. 5 illustrates an exemplary computer system equipped with a NIC that facilitates dynamic management of non-idempotent operations. The computer system 550 includes a processor 552, a memory device 554 and a storage device 556. Memory device 554 may include a volatile memory device (e.g., a dual in-line memory module (DIMM)). Further, the computer system 550 may be coupled to a keyboard 562, a pointing device 564, and a display device 566. The storage device 556 may store an operating system 570. The application programs 572 may operate on an operating system 570.

Computer system 550 may be equipped with a host interface to couple NIC 520 that facilitates efficient data request management. The NIC 520 may provide one or more HNIs to the computer system 550. NIC 520 may be coupled to switch 502 via one of the HNIs. NIC 520 may include an operation management logic block 530 (e.g., in PCT 324 or 334 in fig. 3A and 3B). If NIC 520 is operating as an originating NIC, operations management logic 530 may include request logic 532 that generates packets for single and multi-packet requests, each having a corresponding operation. The request logic 532 may store the packet in a retry buffer.

If NIC 520 is operating as a destination NIC, operation management logic 530 may include execution logic 534 and storage logic 536. The execution logic block 534 may execute idempotent operations based on the request from the source NIC without checking whether the corresponding operation is a duplicate operation. After generating the output results, response logic block 536 may include the output results in a packet and forward the packet to the originating NIC.

In summary, the present disclosure describes a NIC that facilitates efficient management of idempotent operations. The NIC may be equipped with a network interface and operation management logic. During operation, the network interface may receive an operation request from a remote device. The operation management logic block may determine whether the request is for an idempotent operation. If the request is for an idempotent operation, the operation management logic may perform the operation to generate an output result and generate a response including the output result to respond to the request.

The methods and processes described above may be performed by hardware logic blocks, modules, or devices. A hardware logic block, module, logic block, or apparatus may include, but is not limited to, an Application Specific Integrated Circuit (ASIC) chip, a Field Programmable Gate Array (FPGA), a dedicated or shared processor that executes code at a particular time, and other programmable logic devices now known or later developed. A hardware logic block, module or device when activated, performs the methods and processes included therein.

The methods and processes described herein may also be embodied as code or data, which may be stored in a storage device or computer-readable storage medium. The methods and processes may be performed by a processor when the stored code or data is read and executed by the processor.

The foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description. The description is not intended to be exhaustive or to limit the invention to the precise form disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the invention is defined by the appended claims.