阅读说明：本技术 促进网络接口控制器(nic)中的数据请求管理的系统和方法 (System and method for facilitating data request management in a Network Interface Controller (NIC) ) 是由 A·M·巴塔耶纳 T·L·科特 D·C·休森 T·J·约翰逊 于 2020-03-23 设计创作，主要内容包括：提供了一种能够促进高效数据请求管理的网络接口控制器(NIC)。NIC可以配备有命令队列、消息切分单元(MCU)和流量管理逻辑块。在操作期间,命令队列可以存储通过主机接口发出的命令。然后,MCU可以确定命令的类型和命令的响应的长度。如果命令是数据请求,流量管理逻辑块可以确定响应的长度是否在阈值内。如果长度超过阈值,则流量管理逻辑块可以对命令进行速度调整使得响应在阈值内。(A Network Interface Controller (NIC) capable of facilitating efficient data request management is provided. The NIC may be equipped with a command queue, a message slicing unit (MCU), and traffic management logic. During operation, the command queue may store commands issued through the host interface. The MCU may then determine the type of command and the length of the command's response. If the command is a data request, the traffic management logic block may determine whether the length of the response is within a threshold. If the length exceeds the threshold, the traffic management logic may speed-adjust the command so that the response is within the threshold.)

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

a command queue for storing commands issued via the host interface;

a message slicing unit (MCU) for determining a type of the command and a length of a response of the command; and

traffic shaping logic to:

in response to the command being a data request, determining whether a length of the response is within a threshold; and

in response to the length exceeding the threshold, speed-adjusting the command such that the response is within the threshold.

2. The network interface controller of claim 1, wherein the data request is a Remote Direct Memory Access (RDMA) GET command.

3. The network interface controller of claim 1, wherein the MCU is further configured to:

dividing the data request into a series of sub-requests; and

including the corresponding sub-request in a request packet; and

wherein the traffic shaping logic is further configured to independently manage the respective sub-requests.

4. The network interface controller of claim 1, wherein the MCU is further configured to generate a data packet associated with the command; and

wherein the network interface controller further comprises a network interface for forwarding the data packet to a switch fabric.

5. The network interface controller of claim 1, wherein the MCU is one of a plurality of MCUs residing on the network interface controller; and

wherein the traffic shaping logic is further to arbitrate between the plurality of MCUs to select the MCU for forwarding the command.

6. The network interface controller of claim 5, wherein the traffic shaping logic is to speed adjust the command by:

selecting a second MCU of the plurality of MCUs for forwarding a second command; and

selecting the MCU for forwarding the command in response to a length of the response to the command falling within the threshold.

7. The network interface controller of claim 5, wherein the NIC further comprises a plurality of flow queues, wherein a respective flow queue corresponds to a unique flow in the network interface controller; and

wherein respective stream queues are allocated to MCUs of the plurality of MCUs.

8. The network interface controller of claim 1, wherein the threshold corresponds to a rate at which the network interface controller is capable of processing responses such that commands are issued at a rate that matches the rate at which the network interface controller is capable of processing responses.

9. A method, comprising:

storing, in a command queue of a Network Interface Controller (NIC), a command issued via a host interface that couples the network interface controller to a host device;

determining, by the network interface controller, a type of the command and a length of a response to the command;

in response to the command being a data request, determining whether a length of the response is within a threshold; and

in response to the length exceeding the threshold, speed-adjusting the command such that the response is within the threshold.

10. The method of claim 9, wherein the data request is a Remote Direct Memory Access (RDMA) GET command.

11. The method of claim 9, further comprising:

dividing the data request into a series of sub-requests;

including the corresponding sub-request in a request packet; and

the corresponding sub-requests are managed independently.

12. The method of claim 9, further comprising:

generating a data packet associated with the command; and

forwarding the data packet to a switch fabric.

13. The method of claim 9, wherein the network interface controller comprises a plurality of message slicing units (MCUs); and is

Wherein the method further comprises arbitrating among the plurality of MCUs to select an MCU for forwarding the command.

14. The method of claim 13, wherein speed adjusting the command further comprises:

selecting a second MCU of the plurality of MCUs for forwarding a second command; and

selecting the MCU for forwarding the command in response to a length of the response to the command falling within the threshold.

15. The method of claim 13, wherein the network interface controller further comprises a plurality of flow queues, wherein a respective flow queue corresponds to a unique flow in the network interface controller; and

wherein respective stream queues are allocated to MCUs of the plurality of MCUs.

16. The method of claim 9, wherein the threshold corresponds to a rate at which the network interface controller can process responses, such that commands are issued at a rate that matches the rate at which the network interface controller can process responses.

17. A computer system, comprising:

a processor;

a Network Interface Controller (NIC); and

a host interface for coupling to the NIC;

wherein the NIC comprises:

a command queue for storing commands issued via the host interface;

a message slicing unit (MCU) for determining a type of the command and a length of a response of the command; and

traffic shaping logic to:

in response to the command being a data request, determining whether a length of the response is within a threshold; and

in response to the length exceeding the threshold, speed-adjusting the command such that the response is within the threshold.

18. The computer system of claim 17, wherein the MCU is further to:

dividing the data request into a series of sub-requests; and

including the corresponding sub-request in a request packet; and

wherein the traffic shaping logic block further independently manages the respective sub-requests.

19. The computer system of claim 17, wherein the MCU is one of a plurality of MCUs residing on the network interface controller; and

wherein the traffic shaping logic is further to arbitrate between the plurality of MCUs to select an MCU for forwarding the command.

20. The computer system of claim 19, wherein the traffic shaping logic is to speed adjust the command by:

selecting a second MCU of the plurality of MCUs for forwarding a second command; and

selecting the MCU for forwarding the command in response to a length of the response to the command falling within the threshold.

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 Network Interface Controllers (NICs) with efficient data request management.

Prior Art

As network-enabled devices and applications become more prevalent, various types of traffic and increasing network loads continue to place more performance demands on the underlying network architecture. For example, applications such as High Performance Computing (HPC), media streaming, and internet of things (IoT) may generate different types of traffic with unique characteristics. Thus, in addition to conventional network performance metrics (such as bandwidth and latency), network architectures continue to face challenges such as scalability, versatility, and efficiency.

Disclosure of Invention

A Network Interface Controller (NIC) capable of facilitating efficient data request management is provided. The NIC may be equipped with a command queue, a message slicing unit (MCU), and traffic management logic. During operation, the command queue may store commands issued through the host interface. The MCU may then determine the type of command and generate a set of request packets based on the command. For a corresponding request packet, the MCU may determine the length of the response (e.g., response packet) for the request packet. If the command is a data request, the traffic management logic block may determine whether the length of the response is within a threshold. If the length exceeds the threshold, the traffic management logic may speed-adjust (pace) the command so that the response is within the threshold.

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. 3 illustrates exemplary efficient data request management in a NIC.

Fig. 4A shows a flow diagram of an exemplary data request throttling process in a NIC.

Fig. 4B illustrates a flow diagram of an exemplary arbitration process for facilitating data request throttling in a NIC.

Fig. 5 illustrates an exemplary computer system equipped with a NIC that facilitates efficient data request management.

In the drawings, like numbering represents 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 efficient data request management in a Network Interface Controller (NIC). The NIC allows the host to communicate with a data driven network.

Embodiments described herein address the problem of network congestion caused by differences in the respective sizes of data requests and responses by (i) identifying data requests in the NIC and determining the size of corresponding responses, and (ii) throttling the rate of requests at the NIC to limit the rate of corresponding responses to within a threshold, if needed.

During operation, a user process, which may be running on an initiator computing device, may generate a data request (e.g., a Remote Direct Memory Access (RDMA) "GET" command) and insert the request into a command queue of the NIC. The process may notify the NIC about the insertion, for example by updating a write pointer. The NIC may retrieve the request and initiate forwarding of the request (e.g., in a message or data packet). However, the NIC may process and forward requests at a higher rate than the rate at which corresponding responses are returned. For example, a request may be relatively small in size (e.g., 48 bytes long), while a corresponding response may be significantly larger in size (e.g., 2048 bytes long).

Thus, a request may require 1 clock cycle of the NIC to issue, but a response message may require 50 clock cycles of the NIC to write response data into the memory of the host device of the NIC. Thus, there may be a 1: 50. If the NIC continues to issue requests every clock cycle, there may be congestion in the network when the response is returned due to the significantly larger size of the response. In particular, if the NIC continues to receive large amounts of data, the corresponding back pressure may cause significant congestion in the network. The larger the response, the more congested the input queue may become.

To address this problem, the NIC may be equipped with a request management system that may examine the corresponding command obtained from the command queue to determine whether the command is a data request. If the command is a data request (e.g., a GET command), the NIC may determine the size of the corresponding response based on the amount of data requested. The NIC may then determine a potential incoming data rate that may be generated by the response. The NIC then determines whether the potential incoming data rate is within a threshold. In some embodiments, the threshold may be set based on the rate at which the NIC is able to absorb responses. In this manner, the rate at which requests are allowed to issue is controlled by the NIC such that the rate matches the bandwidth at which the NIC is able to absorb responses.

One embodiment of the present invention provides a NIC. The NIC may be equipped with a command queue, a message slicing unit (MCU), and traffic management logic. During operation, the command queue stores commands issued through the host interface. The MCU may then determine the type of command and generate a set of request packets based on the command. For a corresponding request packet, the MCU may determine the length of the response (e.g., response packet) for the request packet. If the command is a data request, the traffic management logic determines if the length of the response is within a threshold. If the length exceeds the threshold, the traffic management logic block adjusts the speed of the command so that the response is within the threshold.

In a variation on this embodiment, the data request may be a Remote Direct Memory Access (RDMA) GET command.

In a variation on this embodiment, the MCU may divide the data request into a series of sub-requests and include the corresponding sub-requests in the request packet. The traffic shaping logic block may then manage the corresponding sub-requests independently.

In a variation on this embodiment, the MCU may generate a data packet associated with the command. The NIC may also include a network interface that forwards packets to the switch fabric.

In a variation on this embodiment, the MCU may be one of a plurality of MCUs residing on the NIC. The traffic management logic may then arbitrate among the multiple MCUs to select an MCU for forwarding the command.

In a further variation, the traffic management logic block may speed-adjust the command by selecting a second MCU of the plurality of MCUs to forward the second command, and selecting an MCU to forward the command in response to the length of the response to the command falling within a threshold.

In a further variation, the NIC may also include a plurality of flow queues. The corresponding flow queue may correspond to a unique flow in the NIC. In addition, the respective stream queues may be allocated to MCU units of the plurality of MCU units.

In a variation on this embodiment, the threshold may correspond to a rate at which the NIC is able to process the response. In this manner, the NIC may issue commands at a rate that matches the rate at which the NIC is able to process responses.

In this disclosure, the description in connection with fig. 1 is associated with a network architecture, and the description in connection with fig. 2A and beyond provides more detail regarding the architecture and operation associated with NICs that support efficient data request management.

In this disclosure, packet traffic may also be referred to as "packet flows," or simply "flows. The data path traversed by a flow, along with its configuration information maintained by the switch, may be referred to as a "flow path". Also, the terms "buffer" and "queue" are used interchangeably in this disclosure.

FIG. 1 illustrates an example network that facilitates flow channels. In this example, a network of switches 100 (which may also be referred to as a "switch fabric") may include switches 102, 104, 106, 108, and 110. Host devices 114 and 116 may be equipped with NICs 124 and 126, respectively. If host device 114 issues a command and host device 116 is the target of the command, NICs 124 and 126 may be referred to as a source NIC and a destination NIC, respectively.

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. The respective 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 HI210 and the HNI220, and the NIC 204 may include the HI 211 and the HNI 221.

In some embodiments, the HI210 may be a Peripheral Component Interconnect (PCI) or peripheral component interconnect express (PCIe) interface. The HI210 may be coupled to the host through 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 an aggregate 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 HNI220 may support Institute of Electrical and Electronics Engineers (IEEE)802.3 ethernet-based protocols, as well as enhanced frame formats that support 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 aggregation operations, and ethernet packet processing. When the host issues an MPI message, the NIC 202 may match the corresponding message type. Additionally, the NIC 202 may implement the urgency protocol and the appointment protocol for the MPI, thereby offloading corresponding operations from the host.

Additionally, RMA operations supported by the NIC 202 may include PUT, GET, and Atomic Memory Operations (AMO). The NIC 202 may provide reliable transport. For example, if the NIC 202 is an originating NIC, the NIC 202 may provide a retry mechanism for idempotent operations. Additionally, 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 manner, the NIC 202 may eliminate the burden from the host (e.g., software). The policy specifying the retry mechanism may be specified by the host through the driver software, thereby ensuring flexibility in the NIC 202.

Additionally, the NIC 202 may facilitate the scheduling of trigger operations, generic mechanisms for offloading, and dependent sequences of operations (such as bulk data collections). NIC 202 may support an Application Programming Interface (API) (e.g., libfabric API) that facilitates providing 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 the Portals API. Further, the NIC 202 may provide efficient ethernet packet processing, which may include efficient transmission if the NIC 202 is the sender, flow direction if the NIC 202 is the destination, and checksum calculation. Also, 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 macros of the HNI220 may facilitate low-level ethernet operations, such as Physical Coding Sublayer (PCS) and Media Access Control (MAC). In addition, the NIC 202 may support Link Layer Retry (LLR). Incoming packets may be parsed by parser 228 and stored in buffer 229. The buffer 229 may be a PFC buffer provided to buffer a threshold amount (e.g., 1 microsecond) of delay bandwidth. HNI220 may also include a control transmitting unit 224 and a control receiving 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. Based on the hash function, the initiator command is sorted into the flow queue 236. One of the flow queues 236 may be assigned to a unique flow. In addition, CQ unit 230 may also include a trigger action module (or logic block) 238 responsible for queuing and dispatching the triggered commands.

Outbound transport engine (OXE)240 may pull commands from flow queue 236 in order to process them for dispatch. OXE240 may include an Address Translation Request Unit (ATRU)244, which may send an address translation request to Address Translation Unit (ATU) 212. ATU212 may provide virtual-to-physical address translation on behalf of different engines, such as OXE240, inbound transport engine (IXE)250, and Event Engine (EE) 216. ATU212 may maintain a large translation cache 214. ATU212 may either perform the translation itself or use a host-based Address Translation Service (ATS). OXE240 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 becomes 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 may then send the packet header, the corresponding traffic class, and the packet size to the traffic shaper 248. Shaper 248 may determine which requests presented by MCU 246 may proceed to the network.

The selected data packet may then be sent to a Packet and Connection Tracking (PCT) 270. PCT 270 may store the data packet in queue 274. The PCT 270 may also maintain status information for outbound commands and update the status information when a response is returned. PCT 270 may also maintain packet status information (e.g., allow responses to match requests), message status information (e.g., track progress of multi-packet messages), initiator completion status information, and retry status information (e.g., 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 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 necessary status of reliable delivery of packets and message completion notifications. The PCT 270 may forward the outbound packet to the HNI220, which the HNI220 stores in the outbound queue 222.

The NIC 202 may also include an IXE 250, the IXE 250 providing packet processing if the NIC 202 is the target or destination. The IXE 250 may obtain the incoming data packet 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 a buffer. 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 and unexpected messages. MST 266 may store the matching results and the information needed to generate the target side completion event. MST 266 may be used by unlimited operations, including multi-packet PUT commands as well as single packet and multi-packet GET commands.

The parser 256 may then store the packet in the packet buffer 254. The IXE 250 can obtain the matching result for the conflict check. The DMA write and AMO module 252 may then issue the updates generated by the write and AMO operations to the memory. If the 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, which EE 216 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 can manage an event queue located in host processor memory to which it writes complete events. EE 216 may forward the count event to CQ element 230.

Request management in NICs

Fig. 3 illustrates exemplary efficient data request management in a NIC. If a host process generates a data request, such as a GET command, the process may write the request to one of command queues 232. The process may notify the NIC 202 of the insertion by updating the write pointer of the command queue 232. The NIC 202 may retrieve the request and initiate forwarding the request. However, the NIC 202 may process and forward requests at a higher rate than the rate at which corresponding responses are returned. For example, a request may require 1 clock cycle of the NIC 202 to issue, but a response message may require 50 clock cycles of the NIC 202 to obtain the requested data. Thus, there may be a 1: 50. If the NIC 202 continues to issue requests every clock cycle, there may be congestion when responses are returned due to the significantly larger size of the response.

To address this issue, OXE240 may examine a corresponding command (such as request 312) obtained from command queue 232 to determine whether request 312 is a data request. In some embodiments, OXE240 may perform deep packet inspection (e.g., by inspecting an internal header within the payload of request 312) to determine the command type of request 312. The NIC 202 may also determine the type based on MPI matching. When request 312 is determined to be a data request, OXE240 may determine the size of the corresponding response based on the amount of data requested by request 312. OXE240 may then determine a potential incoming data rate that may be generated by the response. OXE240 may then determine whether the potential incoming data rate is within a threshold. In some embodiments, the threshold may be set based on the rate at which the NIC 202 is able to absorb or process responses.

Request 312 may be assigned to flow queue 320 in flow queue 236 based on the flow associated with request 312. OXE240 may obtain request 312 from stream queue 320 and provide request 312 to MCU module 302 (e.g., in MCU 246) that has been assigned to stream queue 320. Similarly, OXE240 may obtain requests 314 and 316 from the respective stream queues and provide request 312 to MCU modules 304 and 306, respectively. It should be noted that MCU 246 may include a plurality of MCU modules, each of which may correspond to a stream queue of stream queues 236.

MCU module 302 may maintain an OrdPktActive count of outstanding packets, such as packets associated with request 312. MCU module 302 can increment the OrdPktActive count when constructing a packet for a message and decrement the count when MCU module 302 observes a response processed by PCT 270. MCU module 302 can stop the generation of request packets when the OrdPktActive count exceeds a threshold defined in a register. The threshold may indicate an appropriate limit. Since throttling the rate of requests depends on the expected response length of the respective request, MCU module 302 may determine a value for RspPktLen for request 312 that indicates the length of the response packet. MCU module 302 may calculate RspPktLen based on the payload of request 312 (e.g., the amount of data requested).

In some embodiments, traffic shaper 248 may determine from which MCU module in MCUs 246 to fetch the next packet to be transmitted. Traffic shaper 248 may select an MCU module based on priority flow control from the link partner, bandwidth sharing between different traffic shaping classes, and bandwidth sharing between MCU modules within a class. By arbitrating between MCU modules, traffic shaper 248 may throttle (or rate) request packets to match the expected rate of corresponding responses. In this manner, the traffic shaper 248 may manage the outbound and inbound bandwidths utilized by applications running on the host. Since an application may perform bulk data transfers using a combination of data transfers (e.g., PUT commands) and data requests (e.g., GET commands), traffic shaper 248 may classify PUT requests and GET responses as consuming bandwidth for outbound data packets and may assign the sum of these to a bandwidth policy.

In this example, traffic shaper 248 may obtain the respective OrdPktActive and RspPktLen for requests 312, 314, and 316 from MCU modules 302, 304, and 306, respectively. Traffic shaper 248 may determine that the response to request 312 is within a threshold. Traffic shaper 248 may therefore select MCU module 302 based on arbitration, obtain request 312, and place request 312 in output buffer 242 for forwarding. However, the traffic shaper 248 may determine that the response to the request 314 may exceed a threshold. Thus, traffic shaper 248 may skip MCU module 304 based on arbitration, thereby avoiding the selection of MCU module 304 for forwarding.

The traffic shaper 248 may then determine that the response to the request 316 is within a threshold. Traffic shaper 248 may then select MCU module 306 based on arbitration, obtain request 316, and place request 316 in output buffer 242. Traffic shaper 248 may select MCU module 304 for forwarding request 314 when the length of the response to request 314 falls within a threshold based arbitration process. In this manner, MCU modules 302, 304, and 306 may process requests, such as GET commands, and traffic shaper 248 performs speed adjustments on MCU modules 302, 304, and 306 with arbitration between them. Since the MCU module provides the request, traffic shaper 248 may speed-adjust the request by speed-adjusting the MCU module.

Fig. 4A shows a flow diagram of an exemplary data request throttling process in a NIC. During operation, the OXE of the NIC may obtain a command from the flow queue (operation 402). The OXE may then determine the type of command (operation 404) and check whether the command is a data request (e.g., a GET command) (operation 406). Subsequently, the OXE may determine a response size of the data request (operation 408) and determine whether a response length of the data request is within a threshold (operation 410). In some embodiments, the MCU module in OXE may calculate RspPktLen for the command and provide RspPktLen to the packet shaper, which in turn may determine whether the response length is within a threshold. If the response length is within the threshold, OXE may speed-adjust the data request (e.g., by throttling the transmission rate of the data request) (operation 412). On the other hand, if the response length is within the threshold, the OXE may provide the data request for tracking and forwarding (operation 414).

Fig. 4B illustrates a flow diagram of an exemplary arbitration process for facilitating data request throttling in a NIC. During operation, the traffic shaper of the NIC determines the presence of a data request in the MCU block (operation 452). In some embodiments, the MCU module may provide information associated with the data request, such as RspPktLen, to the traffic shaper, thereby informing the traffic shaper of the presence of the data request. The traffic shaper may then determine whether the data request requires speed adjustment based on the response length (operation 454). If no speed adjustment is needed, the traffic shaper may select an MCU module for forwarding (operation 456). However, if the data request requires speed adjustment, the traffic shaper may refrain from selecting an MCU block for forwarding (operation 458) and continue arbitrating for subsequent MCU blocks (operation 460). Subsequent MCU modules may be selected according to the arbitration policy of the NIC. Examples of arbitration policies include, but are not limited to round robin (round bin) selection, load based selection, priority based selection, and availability based selection.

Exemplary computing device

Fig. 5 illustrates an exemplary computer system equipped with a NIC that facilitates efficient data request management. 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)). Additionally, 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 572 may operate on an operating system 570.

The computer system 550 may be equipped with a host interface coupled to the NIC 520, the NIC 520 facilitating 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 through one of the NICs. As described in connection with fig. 2B, NIC 520 may include OXE logic block 530. The OXE logic block 530 may include MCU logic block 532 that may obtain commands (such as GET or PUT commands). The command may be issued by the application 572 via a host interface. The MCU logic block 532 may determine the type of command and the length of the command's response. The MCU logic 532 may provide these pieces of information to the traffic shaping logic 534 of the OXE logic 530. The traffic shaping logic block 534 may also include speed adjustment logic block 536 and arbitration logic block 538. The speed adjustment logic block 536 may determine whether the command requires a speed adjustment based on the type of command and the length of the response of the command. The arbitration logic block 538 may arbitrate among a set of MCUs of the MCU logic block 532. If the command requires a speed adjustment, arbitration logic block 538 may refrain from selecting the corresponding MCU, thereby performing a speed adjustment on the data request in NIC 520.

In summary, the present disclosure describes a NIC that facilitates efficient data request management. The NIC may reside in a computer system that may further include a processor, a memory device, and a host interface configured to couple to the NIC. The NIC may be equipped with a command queue, MCU and traffic management logic. During operation, the command queue stores commands issued through the host interface. The MCU may then determine the type of command and the length of the command's response. If the command is a data request, the traffic management logic determines if the length of the response is within a threshold. If the length exceeds the threshold, the traffic management logic block adjusts the speed of the command so that the response is within the threshold.

The methods and processes described above may be performed by hardware logic blocks, modules, logic blocks, or devices. A hardware logic block, module 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 strips at a particular time, and other programmable logic devices now known or later developed. When activated, the hardware logic blocks, modules, or devices perform the methods and processes contained within them.

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. They are not intended to be exhaustive or to limit the invention to the forms 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.