Programmable congestion control

Abstract

A network adapter includes a receive (RX) pipe, a transmit (TX) pipe, a hardware-implemented congestion control circuit, and a congestion control processor. The RX pipe is configured to receive packets from a network and process the received packets. The TX pipe is configured to transmit packets to the network. The hardware-implemented congestion control circuit is configured to receive congestion control (CC) events from the TX pipe and the RX pipe, which are derived from at least some packets transmitted to the network and at least some packets received from the network, and pre-process CC events. The congestion control processor is configured to receive the pre-processed CC events from the congestion control circuit, and in response to the pre-processed CC events, limit the transmission rate of packets transmitted by the TX pipe to the network.

Description

Technical Field

[0001] The present invention relates generally to packet communication networks and, more particularly, to methods and systems for congestion control in such networks. Background Art

[0002] Congestion management of packet traffic in communication systems is very important because poor congestion control may severely affect system performance.

[0003] Some congestion control techniques are used in the industry, for example, Almeida and Belo, "Explicit rate congestion control with binary notifications", presented at the 10th IEEE Symposium on Local and Metropolitan Area Networks, November 21-24, 1999, describes a rate-based source adaptation algorithm for packet-switched networks in which binary notifications are sent to the source reflecting the positive or negative difference between the source rate and the estimated fair rate, and based on these notifications, the source increases or decreases the transmission rate.

[0004] Internet Engineering Task Force (IETF) RFC 3168, published in September 2001, entitled "The Addition of Explicit Congestion Notification (ECN) to IP", specifies the incorporation of ECN (Explicit Congestion Notification) into TCP and IP, including the use of two bits of ECN in the IP header. Summary of the invention

[0005] Embodiments of the present invention described herein provide a network adapter comprising a receive (RX) pipe, a transmit (TX) pipe, a hardware-implemented congestion control circuit, and a congestion control processor. The RX pipe is configured to receive packets from a network and process the received packets. The TX pipe is configured to transmit packets to the network. The hardware-implemented congestion control circuit is configured to receive congestion control (CC) events from the TX pipe and the RX pipe, the congestion control (CC) events being derived from at least some packets transmitted to the network and at least some packets received from the network, and pre-processing CC events. The congestion control processor is configured to receive the pre-processed CC events from the congestion control circuit, and in response to the pre-processed CC events, limit the transmission rate of packets transmitted by the TX pipe to the network.

[0006] In one embodiment, the network adapter further comprises a direct hardware implemented point-to-point interface configured to communicate at least some of the pre-processed CC events from the congestion control circuit to the congestion control processor.

[0007] In some embodiments, the congestion control circuit includes an event queue configured to queue the CC events, and circuitry configured to pre-process the queued CC events. In one embodiment, the circuitry is configured to discard one or more queued CC events and only provide the CC events that have not been discarded to the congestion control processor. In another embodiment, the circuitry is configured to merge two or more queued CC events and provide the merged CC events to the congestion control processor.

[0008] In the disclosed embodiment, the congestion control processor supports an application program interface (API) for receiving a user-defined congestion control (CC) software code and limiting the transmission rate by running the CC software code.

[0009] In some embodiments, the congestion control circuit is further configured to transmit a first round trip time (RTT) packet through the TX pipe and receive a second RTT packet sent from a peer network adapter through the RX pipe in response to the first RTT packet, and the congestion control processor is configured to estimate a round trip propagation time between the network adapter and the peer network adapter based on the first RTT packet and the second RTT packet, and to limit the transmission rate according to the round trip propagation time.

[0010] According to an embodiment of the present invention, a network adapter is also provided, which includes a receive (RX) pipeline, a transmit (TX) pipeline and a hardware-implemented circuit. The RX pipeline is configured to receive packets from a network and process the received packets. The TX pipeline is configured to transmit packets to the network. The hardware-implemented circuit is configured to receive a first round-trip time (RTT) packet sent from a peer network adapter from the RX pipeline, generate a second RTT packet in response to the first RTT packet, and send the second RTT packet to the TX pipeline for transmission to the peer network adapter.

[0011] In some embodiments, the hardware-implemented circuit is configured to insert one or more timestamps in the second RTT packet, the timestamps indicating a time difference between (i) the first RTT packet arriving at the network adapter and (ii) the second RTT packet leaving the network adapter.

[0012] According to an embodiment of the present invention, a method is also provided, comprising: using a receive (RX) pipe of a network adapter, receiving packets from a network and processing the received packets, and using a transmit (TX) pipe of the network adapter to transmit packets to the network. Using a hardware-implemented congestion control circuit in the network adapter to receive congestion control (CC) events from the TX pipe and the RX pipe, the congestion control (CC) events are derived from at least some packets transmitted to the network and at least some packets received from the network. Preprocessing the CC events by the hardware-implemented congestion control circuit. Using a congestion control processor in the network adapter, receiving the preprocessed CC events from the congestion control circuit, and limiting the transmission rate of packets transmitted to the network through the TX pipe in response to the preprocessed CC events.

[0013] According to an embodiment of the present invention, a method is also provided, including using a receive (RX) pipe in a network adapter to receive packets from a network and process the received packets, and using a transmit (TX) pipe of the network adapter to transmit packets to the network. A circuit implemented in hardware in the network adapter is used to: (i) receive a first round-trip time (RTT) packet sent from a peer network adapter from the RX pipe, (ii) generate a second RTT packet in response to the first RTT packet, and (iii) send the second RTT packet to the TX pipe for transmission to the peer network adapter.

[0014] According to the following detailed description of the embodiments of the present invention, together with the attached Figure 1 The present invention will be more fully understood, wherein: BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a block diagram schematically depicting a remote direct memory access (RDMA) over a converged Ethernet (RoCE) architecture with congestion mitigation according to an embodiment of the present invention;

[0016] Figure 2 is a block diagram schematically showing a structure of a transmission network interface controller (NIC) according to an embodiment of the present invention;

[0017] Figure 3A is a timing diagram schematically illustrating receiving a congestion notification packet (CNP) in a congestion control scenario according to an embodiment of the present invention;

[0018] Figure 3B is a timing diagram schematically illustrating starting a new packet flow in a congestion control scenario according to an embodiment of the present invention;

[0019] Figure 4is a block diagram schematically illustrating a round trip delay (RTT) measurement process in a network according to an embodiment of the present invention;

[0020] Figure 5 is a flow chart schematically describing the development of congestion control (CC) software executed by a congestion control processor (CCP) in a NIC according to an embodiment of the present invention;

[0021] Figure 6 is a block diagram schematically showing a structure of a congestion control circuit (CCC) in a NIC according to an embodiment of the present invention;

[0022] Figure 7 is a diagram schematically illustrating the operation of a Weighted Random Early Discard (WRED) unit according to an embodiment of the present invention;

[0023] Figure 8 is a block diagram schematically showing a structure of CCP control according to an embodiment of the present invention; and

[0024] Fig. 9 is a state diagram schematically showing a finite state machine (FSM) of CCP control according to an embodiment of the present invention. DETAILED DESCRIPTION

[0025] Overview

[0026] The Transmission Control Protocol (TCP) was introduced in 1974, but its congestion control (CC) algorithm has continued to evolve. The CC algorithm changes the transmission rate of packets from the source (e.g., a network adapter in a source node) that transmits packets in response to congestion notifications received by the source. Congestion notifications are usually added to the packet stream (either as a separate packet or as additional information to an existing packet). When the packet reaches its destination (e.g., a network adapter in a destination node), the destination sends a congestion notification back to the source, which can reduce the transmission rate in response to the notification (or increase the rate if no congestion notification was received).

[0027] Many CC algorithms have been (and still are) proposed that set the transmission rate in response to congestion notifications (see, for example, US Pat. No. 7,000,025). The algorithms are typically flow-oriented and the rate of each packet flow is independently controlled in response to congestion notifications related to packets of the same flow.

[0028] Congestion control (CC) algorithms are usually implemented by software or dedicated hardware running on the host processor. Implementing software on the host has some major disadvantages. First, host software implementations usually exhibit longer latencies, which are caused by the context switches required to process congestion notifications; second, host software implementations consume a lot of CPU resources; and finally, algorithms implemented by host software require communication between the network adapter and the host over the bus. On the other hand, software implementations are usually flexible, allowing easy adaptation to new CC algorithms and changes in network configurations, while hardware implementations tend to be rigid and difficult to modify.

[0029] According to the embodiments of the present invention disclosed herein, a network adapter with flexible and fast congestion control is provided. (For clarity, the following description mainly refers to a network interface controller (NIC). However, the disclosed technology is by no means limited to Ethernet NICs; in embodiments according to the present invention, any other suitable network adapter may be used, including, for example, Infiniband Host Channel Adapter (HCA)).

[0030] In some embodiments, the NIC includes a congestion control circuit (hereinafter referred to as "CCC") and a dedicated congestion control programmable processor ("CCP", also referred to as "processor") tightly coupled to the communication port. In response to the traffic load of the network, the processor can limit (reduce or increase) the transmission rate of packets. In an embodiment, the NIC is configured to send, return and receive round-trip delay (RTT) measurement packets, which may be useful for setting the transmission rate (to be described below).

[0031] NIC generally includes one or more ingress ports, which receive packets from the network and send the packets to an input queue; and one or more egress ports, which receive packets from an output queue and send the packets to the network. In the following description, the aggregation of the ingress port and the input queue is referred to as a receive pipe, and the output queue and the egress port are aggregated as a transmit pipe.

[0032] In one embodiment, the CCC includes an event queue configured to receive TX notifications and RX notifications related to packet transmission and reception, respectively, and to send event notifications to the CCP. The CCC typically receives TX notifications for each predefined burst of transmitted packets and RX notifications for the following received packets: positive and negative acknowledgement (ACK and NACK) packets; congestion notification packets (packets sent back by a peer network adapter in response to transmitted packets); and returned RTT measurement packets.

[0033] In some embodiments, to avoid congestion in the event queue, the CCC is configured to discard (drop) certain events in response to fullness of the queue (do not confuse this congestion with congestion in the network).

[0034] In some of the example embodiments below, reference will be made to Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCE); however, the techniques disclosed herein are not limited to RoCE and may be used in any suitable network configuration.

[0035] According to some implementations, the event types stored in the event queue include:

[0036] 1.TX - transmit burst of packets;

[0037] 2.CNP-Receive Congestion Notification Packet (CNP);

[0038] 3. NACK - Receive NACK;

[0039] 4.ACK-Receive ACK;

[0040] 5. RTT—receive a response packet to a round trip delay (RTT) measurement packet (described below); and

[0041] 6. Host injection event (described below).

[0042] In some implementations, events are represented in the CCC queue by entries that include an event type field, a timestamp field, a sequence number field, a stream identification field, a field representing the number of bytes sent for the Tx event, and a field for other RTT receive event timestamps.

[0043] In some embodiments according to the present invention, in addition to events generated by the Tx pipe and the Rx pipe, CC events also include firmware generated events, which can be defined by the user of the NIC and provide algorithm flexibility.

[0044] In some embodiments according to the invention, the CCC includes an arbiter (e.g., polling) that selects events to be processed from an event queue or firmware events. In some embodiments, the number of event types can be greater than the number of event types that the CCC can handle, and a mapping can be employed that maps more than one event type to the same "event category."

[0045] In some embodiments according to the present invention, the CCC further comprises a CCP control unit (also referred to as "CCP control" for simplicity), which is configured to merge CC events and submit the events and merge the events into the CCP as inputs of the CC algorithm executed by the CCP. In one embodiment, the CCP control comprises a content addressable memory (CAM) that receives congestion events from a congestion queue. The CAM is configured to compare the flow index of the congestion event with the flow index that has been assigned to the CCP processor (the number of indexes stored in the CAM is not greater than the number of processors in the CCP), and point to the processor whose flow index matches; or if no match is found, indicate "no match".

[0046] In various embodiments, the CCP control further includes CCQ fragments (one fragment per CCP processor) and a fragment arbiter, wherein each fragment includes a finite state machine (FSM), and the FSM includes an idle state, a busy state, and an arbitration state. Starting from the idle state, when the CCQ fragment receives an event, the CCQ fragment enters the arbitration state; the fragment arbiter determines which fragment in the arbitration state will activate the non-busy CCP processor; then, the CCQ fragment selected by the arbiter enters the busy state and returns to the idle state when the corresponding processor signals completion (as described below, the CCQ fragment includes additional states to support merging). In one embodiment, the CCP control sends the index of the processor selected by the fragment arbiter, the corresponding flow index, and an optional hash of the flow index to the CCP.

[0047] In some embodiments, when a CCP processor updates a rate and / or requests an RTT measurement, the CCP sends a rate and a request with a processor ID; the CCP control is configured to read a flow label corresponding to the processor ID (from the CAM) and send the flow label with the updated rate and / or RTT request to the transmit pipe.

[0048] merge

[0049] In some embodiments, to improve performance, the CCP control includes a merging circuit configured to compress multiple congestion events corresponding to the same flow and the same event class into a single "merged event". When such a merged event is assigned to a processor, the processor will process the merged event instead of processing each original event individually. Since fewer context switches (associated with assigning new tasks to a processor) are required, the efficiency of congestion handling is improved. In addition, by merging, a situation is avoided in which an event corresponding to a first flow and waiting for a processor blocks events corresponding to other flows.

[0050] In one embodiment, the CCP control also includes a merging unit and an FF array. For each processor and each event category of the CCP, the FF array includes an entry in which the cumulative data of all merged events corresponding to the same processor and category are stored. When a new event is received, the merging unit will update the corresponding entry in the FF array. For example, the FF array entry includes a send byte field that counts the number of bytes in the send packet event generated by the transmission pipeline. When the CCC receives a new send packet event, the merging unit will increase the send byte field of the corresponding FF array entry accordingly. In another example, each FF array entry includes a first sequence number (SN) field and a last SN field. When the first event is merged, the SN of the event is stored in the first SN field and the last SN field of the corresponding FF array entry; when further events are merged into the same FF array entry, only the last SN field will be updated.

[0051] In an embodiment, each CCQ fragment also includes more working states. When a new event is merged into an existing FF array entry, the corresponding CCQ fragment will enter the more working state; when the corresponding processor sends a completion signal, the CCQ fragment will re-enter the arbitration state and request the CCP processor.

[0052] In some implementations, firmware can rewrite the CCP processor, and each CCP fragment includes additional state to support firmware rewriting and firmware release.

[0053] CCP

[0054] In various embodiments, the CC algorithm run by the CCP includes multiple concurrent processes, each of which controls congestion in a single packet flow. Each process is configured to receive events related to the corresponding flow, update the rate (and possibly request an RTT measurement), and then pause until the next event is received. To allow a limited number of processors to execute, each process is allocated a context in memory; a process can be paused by storing the context and resumed by reading the stored context (because the number of possible contexts can be large, contexts associated with inactive flows are typically stored in slower memory and read by the processor when needed).

[0055] According to some embodiments, the CCP includes multiple independent processors, and the events sent by the CCC to the CCP for processing are assigned to the processors that are not busy. The processor assigned to process the event reads the corresponding context, then runs the process, possibly changing the transmission rate of the flow and / or requesting RTT measurement, and finally stores the updated context in preparation for processing the next event.

[0056] RTT

[0057] In an embodiment according to the present invention, reliable measurement of packet round trip delay (RTT) is an important parameter of the CC algorithm. RTT measurement is usually done by calculating the time difference from sending a packet to receiving the corresponding ACK; however, this measurement technique is not accurate because ACK is initiated by the processor, and RTT measurement will include the time taken by the software response.

[0058] Some embodiments according to the present invention support RTT measurement packets that are sent from a sender network interface controller (NIC) to a receiver NIC, which returns the packet to the sender NIC. The sender NIC adds a first timestamp to the sent packet; when the packet is received, the receiver NIC adds a second timestamp to the packet, routes the packet back to the sender NIC, and adds a third timestamp when sending the packet back. The sender NIC can then accurately calculate the RTT by observing the three timestamps (and the time when the return packet arrives) and divide it into multiple segments, including the time from the sender NIC to the receiver NIC, the time within the receiver NIC, and the time from the receiver NIC to the sender NIC (return packet).

[0059] System Description

[0060] Figure 1 1 is a block diagram schematically illustrating a RoCE architecture 100 with congestion relief according to an embodiment of the present invention. Transmitting NIC 102 transmits packets to receiving NIC 106 via network 104. (It should be noted that both the transmitting NIC and the receiving NIC are configured to transmit and receive packets; the above terms "transmit" and "receive" refer to the direction of congestion relief).

[0061] The transmit NIC 102 includes a transmit (TX) pipe 108 that queues and arbitrates packets for transmission by the NIC and sends the packets to the network 104. Figure 1 The illustrated example embodiment network includes a switch 110 that marks packets sent by a transmit NIC with an explicit congestion indication (ECN) when congested.

[0062] The receiving NIC 106 sends return packets back to the transmitting NIC, including packets for congestion control (in Figure 1 When the receiving NIC receives a packet with an ECN indication, the receiving NIC sends the CNP packet back to the sending NIC.

[0063] Transmit NIC 102 also includes a receive (RX) pipe 112 , which receives input packets from the network, and a congestion control unit 114 .

[0064] Congestion control 114 is configured to execute a congestion control algorithm and alleviate congestion in the RoCE transmission path. Congestion control includes a congestion control processor (CCP) 116 configured to run a congestion control algorithm and a congestion control circuit (CCC) 118 configured to send congestion events to the CCP.

[0065] CCC 118 receives Tx events when transmit pipe 108 sends bursts of packets, and receives Rx events when receive pipe 112 receives congestion control packets. (Received congestion control packets may include, for example, ACKs and NACKs received in response to transmitted packets, CNP packets generated by the receiving NIC in response to receiving ECN-tagged packets, and RTT measurement packets.)

[0066] The CCC queues the events and sends at least some of the events to the CCP via a hardware-implemented direct point-to-point interface 120. In this context, the term "direct point-to-point interface" refers to an interface that does not involve communication via a bus, interrupts, or any other operating system calls. The CCP processes these events and runs a congestion control algorithm to calculate the required transmission rate for additional packets, then notifies the transmission pipeline 108 of this rate and optionally requests the transmission pipeline to send RTT measurement packets.

[0067] In some implementations, the CCP runs a congestion control algorithm for each packet flow individually and determines the transmission rate for each flow individually.

[0068] In an embodiment according to the invention, communication between the CCC and the CCP does not involve operating system calls - the CCP signals its readiness to process events (eg, by asserting a dedicated signal) and then reads the events on an input bus driven by the CCC.

[0069] Therefore, according to Figure 1 In an example implementation of the invention, congestion events are queued by a dedicated circuit and submitted to a dedicated processor that runs a congestion control algorithm, modifying the transmission rate accordingly. The overhead associated with running the algorithm is small, and the flexibility to change the congestion control algorithm is retained.

[0070] As will be appreciated, the configuration of the RoCE architecture 100 is an example configuration, which is depicted purely for conceptual clarity. Other suitable configurations may be used in alternative embodiments of the present invention. For example. Instead of (or in addition to) RoCE, the architecture may be TCP and / or aggregated non-volatile memory (NVM) storage (e.g., hyper-aggregated NVM-f). Congestion events received by CCC 118 may be pre-ordered by additional hardware or software; the rate at which the transport pipe sends packets may be controlled by CCP 116 and other algorithms of transport NIC 102.

[0071] Figure 2 2 is a block diagram 200 schematically illustrating the structure of a transmit NIC 102 according to an embodiment of the present invention. (For clarity, it should be noted that the transmit NIC and receive NIC may be the same or similar, but the congestion control circuit is activated when the NIC is used as a transmit NIC. In addition, when both directions are congested, the same NIC may be configured as both a transmit NIC and a receive NIC.)

[0072] The transmit NIC includes a transmit pipe 108, a receive pipe 112, a congestion control processor (CCP) 116, and a congestion control circuit (CCC) 118 (the above units refer to Figure 1 described).

[0073] The transmit conduit 108 sends notifications about packets transmitted by the NIC to the CCC. In one embodiment, the transmit conduit sends notifications about bursts of transmitted packets; in other embodiments, only notifications about a predefined subset (e.g., about packets flowing out through a predefined port) are sent.

[0074] The receiving channel 112 sends a congestion control notification to the CCC. Figure 2 In an example embodiment, such notification includes a notification by a receiving NIC (e.g., Figure 1 The NIC 106 of the sending NIC sends a congestion notification packet (CNP), an ACK packet, a NACK packet, and an RTT measurement packet back to the sending NIC. In some embodiments, the CCC receives only some notifications; for example, according to the ingress port receiving the notification.

[0075] The CCC queues notifications from the receive and transmit pipelines, pre-processes the events, and then forwards congestion control (CC) events to the CCP via a direct point-to-point interface 120. In an embodiment according to the present invention, the CC events output by the CCC are generally not the same as the CC events received by the CCC; instead, the output events may be diluted, merged, and transformed as described below.

[0076] CCP 116 runs the CC algorithm. CC events output by the CCC are input to the CCP. Based on the algorithm, the CCP sometimes changes the transmission rate. Sometimes, the CCP may request the transmission pipeline to send an RTT measurement packet.

[0077] CCP 116 includes a processor farm 202, which includes multiple processors, and CCP context storage 204 (typically RAM). According to an embodiment, the CC algorithm runs separately for each flow of packets; whenever a new event is received from the CCC, the algorithm will rerun and update the transmission rate of the corresponding flow in response to the new event (if no context is encountered for each flow, the processor starts from the initial context). Figure 2 In the example implementation shown, a context is allocated for each flow in the CCP context store; the context includes all data required to continue the CC algorithm after execution has stopped.

[0078] When a new CC event is received from the CCC, the event is assigned to one of the processors of the processor farm. The processor then reads the context corresponding to the stream of events and continues to run the CC algorithm, updating the rate calculation in response to the new event. When the processor completes the calculation of the updated rate, the processor sends the rate to the transmission pipeline 108, stores the updated context in the CCP context storage 204, and stops (or directly starts processing new events).

[0079] Due to the large number of possible flows, it may not be practical to store all contexts in the CCP context storage 204. Instead, contexts for some less active flows may be stored in a larger (and slower) memory and loaded into the CCP context storage when needed. In some embodiments, the CCP context storage 204 includes a cache memory that is updated from main memory when the cache misses.

[0080] In summary, the CCC receives notifications about transmitted packets from the transmit pipe and notifications about congestion control packets from the receive pipe. The CCC queues events and outputs pre-processed events to the CCP. The CCP includes multiple processors and context storage; each processor that obtains an event reads the corresponding context (i.e., the context related to the same packet flow) and runs the CC algorithm. Since the value of RTT may be required by the algorithm, the processor may request the transmission of an RTT measurement packet. The processor updates the transmission rate and stores its context in the context storage after completion.

[0081] The interface between the CCC and CCP is very efficient because no operating system calls are required; context reads and writes are typically completed in 1 to 4 clock cycles.

[0082] It is understandable that the example cited Figure 2The structure of CCC 118 and CCP 116 shown. Congestion control circuits and congestion control processors according to the disclosed technology are not limited to the above description. In alternative embodiments, for example, more events can be monitored, such as Rx events at each received packet. In some embodiments, the CCC can be embedded in the transmission pipeline. In other embodiments, each processor in the server farm can have its own context storage; in other embodiments, each processor can have a cache memory for frequently used contexts.

[0083] Figure 3A 3 is a timing diagram schematically illustrating a CNP reception in a congestion control scenario according to an embodiment of the present invention. The timing diagram includes a CCC timeline 300 and a CCP timeline 302, which respectively illustrate the CCC and CCP ( Figure 1 118 and 116).

[0084] It should be noted that the timing diagram only shows packets associated with a particular flow; packets associated with other flows may be received and processed simultaneously, but are shown here for clarity. Figure 3A Not shown.

[0085] The timing diagram begins (at the top) when the CCC sends a send event 306 to the CCP. The CCP's processor will then enter the CC algorithm execution cycle 304. Figure 3A In the example implementation of , the transmission rate remains unchanged. Next, CCC sends three more transmission bursts 306, and in response, CCP runs the CC algorithm three more times (possibly collecting statistics, but without changing the rate). The time interval between transmission bursts 306 is fixed T1 because the transmission rate does not change.

[0086] Now, the switch between the transmit NIC and the receive NIC becomes congested and marks the packet with ECN. The receive NIC routes the CNP packet back to the transmit NIC, where it is received by the receive pipe and signaled to the CCC. In response, the CCC sends a receive CNP event 308 to the CCP. The CCP will enter the CC algorithm execution cycle 304 again, but this time the algorithm will calculate a lower transmission rate in response to the CNP. The CCP will then send a new transmission rate notification 310 (which may be lower than the previous rate) to the transmit pipe, and in response, will increase the time interval between packet transmissions. The transmit pipe will send subsequent packets at the lower rate (and the CCC will send corresponding send packet events to the CCP), with the distance between transmissions being T2 (T2>T1).

[0087] Note that in the above example the change in rate is immediate and occurs at the next burst after the CNP is received. In an embodiment, the CNP may be received late and still transmit the next packet after T1; the new rate will take effect in one of the subsequent packets.

[0088] Figure 3B Schematically shows a timing diagram of starting a new packet flow in a congestion control scenario according to an embodiment of the present invention. Figure 3A , the timing diagram includes a CCC timeline 300 and a CCP timeline 302; and only displays events related to the stream of interest.

[0089] The sequence diagram begins when CCC sends a send burst 314 to CCP. The corresponding context is stored in CCP context store 204 ( Figure 2 ) - it is new or has been replaced by a more active context in the context store. Next, the CCP sends an indication 316 to the transmission pipe, in which the CCP sets the rate to a preset default rate and requests the CCC to send an RTT measurement packet.

[0090] Now, the transmit pipeline sends the first burst. At the end of the burst, the transmit pipeline adds an RTT request packet. The CCC receives a Tx event 316 with an RTT send indication after T1. The CCP runs the CC algorithm, but lacks new information and does not change the transmission rate.

[0091] As described below, the RTT measurement packet travels through the network to the receiving NIC, which adds a timestamp and directs the packet back to the sending NIC. When the sending NIC receives the returned RTT measurement packet, the CCC sends a notification 320 that the RTT response was received to the CCP. The CCP reenters the CC algorithm execution 304 and, in response to the RTT measurement, calculates a new value for the transmission rate. Figure 3B In the example implementation shown, the rate should be faster than the default (e.g., if the RTT measurement detects a short round trip delay), and the CCP sends a new transmit rate command 322 to the transmit pipe, which is higher than the default rate. The transmit pipe sends the next packet at the higher rate (and the CCP will send a corresponding transmit packet notification), with a delay of T2 (T2 < T1).

[0092] In summary, when a new flow (or a flow without context in the context store) starts, the transmit queue sends packets at the default rate; the CCP requests the transmit pipeline to start RTT measurement. When the RTT measurement response packet arrives, the algorithm calculates the required transmission rate and updates the transmit pipeline accordingly.

[0093] As will be appreciated, Figure 3A , Figure 3BAs shown and described above, the order of events that occur in the transmit NIC is referenced by way of example. The transmit NIC and CC algorithms according to the disclosed technology are not limited to the above description. In alternative embodiments, for example, the transmit rate can be set by a combination of CNP events, RTT measurements, ACK and NACK packets; in other embodiments, when no events are received, the rate can be changed, for example, by default, the rate may be increased to obtain better performance. In some embodiments, when calculating a new rate, the CCP will change the rate step by step; for example, to reduce the rate, the CCP may multiply the rate by a factor less than one in each subsequent packet.

[0094] RTT measurement

[0095] For example, the value of RTT (round trip delay) in a network configuration such as RoCE may be an important parameter of the CC algorithm. The embodiments disclosed herein according to the present invention provide an effective and accurate method to measure RTT, i.e., the round trip propagation time between a transmitting NIC and a receiving NIC. The transmitting NIC is configured to send an RTT measurement packet with a timestamp, and the receiving NIC is configured to add a timestamp and return the measurement packet to the transmitting NIC.

[0096] Figure 4 4 is a block diagram schematically illustrating the RTT measurement flow in a network according to an embodiment of the present invention. The transmitting NIC 102 sends an RTT measurement packet 402, which includes a first timestamp (T1) 404 indicating the time when the packet was transmitted. The packet then traverses the network 104 to the receiving NIC 106. The receiving NIC routes the packet back to the sender, adding a second timestamp (T2) 406 when the NIC receives the packet, and adding a third timestamp (T3) 408 when the NIC sends the return packet. According to an embodiment, the RTT response at the receiving NIC is performed quickly by software without scheduling or queuing.

[0097] When the return packet arrives at the transmit NIC, the transmit NIC can derive the three components of the round-trip time delay:

[0098] The time delay from the transmitting NIC to the receiving NIC – T2-T1;

[0099] The time delay from the ingress port to the egress port in the receiving NIC – T3-T2;

[0100] Time from receiving NIC to transmitting NIC - the difference between the time the packet is received at the transmitting NIC and T3.

[0101] It should be noted that the RTT packet may have other fields not shown, such as the ID of the transmitting NIC and / or receiving NIC, the ingress port and the egress port, etc.

[0102] Therefore, according to an embodiment of the present invention, assuming that the receiving NIC supports RTT measurement, the transmitting NIC can be configured to initiate RTT measurement. The measured RTT can then be used as a parameter of the CC algorithm that the transmitting NIC can run.

[0103] As will be appreciated, by way of example only Figure 4 The structure of the RTT measurement packet shown. The RTT measurement packet according to the disclosed technology is not limited to the above description. In alternative embodiments, more timestamps and other fields may be added. In an embodiment, the receiving NIC may add a time difference instead of an absolute time to the RTT measurement packet.

[0104] User Programmability

[0105] In embodiments according to the invention, the CC algorithm run by the CCP may be changed from time to time by the NIC user, including changes made in the field.

[0106] Figure 5 is a flow chart schematically describing the development of a CC algorithm to be run by a CCP according to an embodiment of the present invention. The flow is performed by a user (usually a programmer).

[0107] The process starts with a write C code step 502, where the user writes the CC algorithm in C code. The user must follow some rules, like a fixed context structure, fixed input API, and output API. The user then compiles the C code in a compile step 504 using, for example, an LLVM intermediate representation (LLVM-IR) compiler 504. The output of the compiler is the target code 506.

[0108] The user can then run the simulator 508 to check how the algorithm will perform in the network. After (or instead of) the simulation, the user performs a program flash step 510, where the user programs the flash memory (or another type of NVM) using the code generated by the compiler. Figure 5 In the example implementation of , the flash memory is protected and the user must provide a security key 512 to enable writing to the flash memory. Finally, in the test / deployment step 514, the user tests the algorithm and, if good, deploys the CC code in the NIC unit.

[0109] Understandably, by citing examples Figure 5The CC development process shown and described above. In alternative embodiments, other suitable development processes may be used, including, for example, Python code programming and the use of other compilers.

[0110] Figure 6 1 is a block diagram schematically showing the structure of a congestion control circuit (CCC) 118 according to an embodiment of the present invention. The CCC includes:

[0111] 1. Tx-Event FIFO 602, which is configured to temporarily store FIFO from the transmit pipeline 108 ( Figure 1 )Received Tx events;

[0112] 2. Rx-event FIFO 604, which is configured to temporarily store Rx CC events received by the FIFO from the receive pipe 112;

[0113] 3. Transmit event weighted random early loss (WRED) unit 606 and receive event WRED 608, which are configured to randomly dilute events (on a per event type basis) from the Tx-FIFO and Rx-FIFO, respectively;

[0114] 4. A firmware event unit 610, which is configured to input CC events (e.g., CC management events) generated by the FW to the CCP;

[0115] 5. A loop selector 612 configured to select a CC event from a Tx event FIFO, an Rx event FIFO or a FW event unit;

[0116] 6. A type-to-category mapper 614 configured to map event types to event categories;

[0117] 7. CCP control unit 616; and

[0118] 8. Tx rate update FIFO 618, which is configured to temporarily store the new rate of the Tx stream.

[0119] Event Type

[0120] according to Figure 6 In the example implementation shown, the events received by the CC from the transmission pipeline and the reception pipeline are classified into seven types:

[0121] 1.TX - the transmit pipe has sent a packet or a burst of packets;

[0122] 2.CNP - Congestion Notification Packet has been received from the receiving NIC;

[0123] 3. NACK - an implicit or explicit (e.g., out-of-sequence (OOS)) NACK has been received;

[0124] 4.ACK-ACK has been received;

[0125] 5. RTT - RTT Measurement Packet Received (sent by the receiving NIC in response to an RTT Measurement Packet already sent by the transmitting NIC);

[0126] 6. RTT sent event - an RTT packet has been sent by the transport pipe (this event is actually a Tx event with an RTT sent indication);

[0127] 7.FW events - CC events generated by FW.

[0128] From the transmission pipeline 108 ( Figure 1 ) enters the Tx-event FIFO 602. Each event includes an event data descriptor, which includes other information in addition to the event type (described below); such as stream number, timestamp, etc. To avoid FIFO overflow, WRED 606 randomly discards (drops) events when the FIFO is full (described below). Figure 7 10. In a similar manner, Rx CC events from the receive pipe 112 enter the Rx-Event FIFO 604, which is protected by the WRED 608 to prevent overflow.

[0129] The FW event unit 610 is configured to generate CC events in response to FW instructions, which are also executed by the CCP. Figure 6 In the example implementation shown, the events generated by the FW event unit do not have a FIFO, and the CCP must process a FW event before receiving a subsequent FW event.

[0130] The loop selection unit 612 sequentially selects CC events from the Tx event FIFO, the Rx event FIFO, and the FW event unit, and forwards the selected events to the event type to class mapper 614. Figure 6 In the example implementation shown, the CCP handles five event categories, while the CC can receive up to seven event types. The event type to category mapper includes a mapping table that maps more than one type to the same category. The table is programmed by the FW.

[0131] Table 1 describes the structure of the mapping table:

[0132] Tx packet sending event Category ID (3 digits) Tx RTT request event Category ID (3 digits) CNP Events Category ID (3 digits) NACK Event Category ID (3 digits) ACK Event Category ID (3 digits) RTT Events Category ID (3 digits) FW Events Category ID (3 digits)

[0133] Table 1

[0134] The type-to-class mapper 614 sends an event indication including the event class to the CCP controller 616. For each event, the type-to-class mapper sends information related to the event. Table 2 lists the information that the type-to-class mapper sends with each event (some more information (which is not indicated below) may be sent in Tx events and FW events):

[0135]

[0136]

[0137] Table 2

[0138] The CCP controls the merged event group and activates the CCP to handle the merged event (see below for more information). Figure 8 616). When the CCP processor is completed, CCP Control 616 further receives an indication from the CCP and receives an updated transmission rate set by the CCP and a request to send an RTT measurement packet. CCP Control then sends the updated rate to Tx Rate Update FIFO 618, which temporarily stores the new rate and sends it to the transmission pipeline when the transmission pipeline is ready to update the rate. CCP Control also sends any RTT measurement requests to the transmission pipeline.

[0139] Figure 7 FIG. 6 schematically shows WRED 606 and 608 according to an embodiment of the present invention. Figure 6 ). A different WRED function can be defined for each event type. The graph includes a horizontal axis 702, which represents queue occupancy; a vertical axis 704, which represents the probability of an event being dropped; and a curve 706, which represents the drop probability function. Two parameters that can be set separately for each event type define the WRED function: a first threshold TH1 and a second threshold TH2.

[0140] The event drop probability is defined as a function of the queue occupancy as follows:

[0141] P = (occupancy rate <TH1)?0:

[0142] (Occupancy <= TH2)? (Occupancy - TH1)*slope:

[0143] (TH2-TH1)*slope;

[0144] (Slope = 1 / (TH2-TH1))

[0145] By carefully programming the parameters of each event type, the user can guarantee that the FIFO will not overflow and that less important event types will be more likely to be dropped as the queue occupancy increases.

[0146] It should be understood that by way of example Figure 7 In alternative embodiments, various suitable probability graphs may be used, including, for example, piecewise linear graphs with more than three slices; graphs that never reach a 100% drop rate; and curved graphs.

[0147] Figure 8 is a schematic diagram showing a CCP control 616 ( Figure 6 ). The CCP control includes a content addressable memory (CAM) 800 configured to locate which processor (if any) is assigned to the flow of a new event; a fragment unit 802 including n CCQ fragments 804, where n is the number of processors in the CCP; a merge unit 806 configured to merge multiple events; an FF array 808 that stores the merged events; an arbiter 810 that selects a CCQ fragment to be assigned to a processor; a multiplexer 812 that selects a flow ID corresponding to the selected CCQ fragment; and a hash 814 that adds a hash key to the selected flow ID.

[0148] When CCP control receives an event from the type to class mapper, the flow ID of the event is directed to the CAM 800 and the fragment 802. The CAM includes n entries, where n is the number of processors. For each entry, the flow ID is stored in the search field, and when the flow ID is asserted at the CAM input, the CAM will search for the ID. If the flow ID is stored in the CAM, the CAM will indicate the corresponding processor ID; if the flow ID is not stored, the CAM will output a random processor ID (not assigned to any other flow ID) and indicate a "no match" (using CAM terminology, a "hit" occurs when it matches the input flow ID, and a "miss" occurs when it does not match). The CAM 800 is also configured to allow direct access to stored flow IDs by specifying the processor ID and performing a read or write operation.

[0149] A hit in the CAM indicates that one of the CCQ fragments is assigned to the incoming event. The new event will be directed to the corresponding CCQ fragment, which will request the arbitrator to assign a processor of the CCP to handle the event (this request may be delayed, as described below). If there is no hit, the CCP waits until there is at least one idle processor, then randomly selects one of the idle processors; the corresponding CCQ fragment will be assigned to the incoming event. In that case, the CAM writes the flow ID into the search field of the entry corresponding to the random processor ID generated by the CAM, so that searches for other events of the same flow will result in a "hit".

[0150] Segment 802 will now be described, which includes CCQ segments 804, one segment per CCP processor. Each CCQ segment 804 includes a FSM.

[0151] Fig. 9 Schematically shows each CCQ fragment 804 ( Figure 8 ) is a state diagram 900 of a finite state machine (FSM). It should be understood that for clarity, the state diagram 900 is simplified and some details are omitted.

[0152] After resetting the system, the FSM is in the idle state 902, waiting for a request to process a new event. When a new event is received, the FSM enters the arbitration state 904, where the CCQ segment requests arbitration (from Figure 8 810 of the arbitrator. When the arbitrator approves the request, the FSM enters the busy state 906, where the corresponding CCP processor will run the CC algorithm with the new event. When the FSM receives a processor completion indication (corresponding to the current processor) from the CCP, if the FSM is still in the "busy" state, the FSM will re-enter the idle state 902.

[0153] When a new event is received while the processor is busy with a previous event, the new event will be merged and the FSM should not enter the idle state. In terms of the FSM, when the FSM is in the busy state 906 and a new event is received, the FSM enters the more work A state 908 (and remains in the more work A state if other new events are received). When the CC fragment receives the processor completion indication, the FSM will enter the arbitration state 904 and will re-arbitrate for other competitor fragments that want access to the processor. (In some embodiments, the more work state 908 is a simplified representation of an additional mechanism that merges additional events received when the FSM is busy; in an embodiment, additional events can also be received when the FSM is in the ARB state 904.)

[0154] As mentioned above, the firmware may wish to override the CC algorithm and calculate the rate in software (ie - not in the CCP processor). The FW drives two signals - the FW Override signal, which indicates that the FW requests to run the CC code, and the FW Release, which indicates that arbitration between CC events can continue.

[0155] When the FSM is in the idle state 902 or in the busy state 906 and the FW asserts the FW-rewrite indication, the FSM will enter the FW state 910, waiting for the FW to complete. When the FW asserts the FW release signal, if the FSM is still in the FW state, the FSM will enter the idle state 902.

[0156] When the FSM is in the Firmware State 910, if a new event is received (and merged), the FSM will enter the More Work B State 912 (and will remain in the More Work B State if more events are received). If the FSM is in the More Work B State and the FW asserts the FW-Release signal, the FSM will enter the Arbitration State 904 and re-arbitrate.

[0157] Now back to Figure 8 The arbiter 810 determines which CCQ segment should be assigned to the CCP processor. Figure 8 In the example implementation shown, a processor may be assigned one at a time (e.g., every clock cycle). The CCQ fragment 804 is also configured to output the corresponding flow ID to the multiplexer 812, which selects the flow ID corresponding to the processor selected by the arbitrator. The CCP control then outputs both the processor ID and the flow ID to the processor in the CCP along with the hashed flow ID (generated by hash 814).

[0158] merge

[0159] FF array 808 includes n segments (n is the number of processors in the CCP). Each FF segment includes five entries, one for each category. Each entry includes event data. When CCP control 616 receives an event, and the processor assigned to handle the event related to the corresponding stream is busy, CCP control merges the event into the corresponding entry in the FF array. When CCP control receives other events of the same stream and the same category, CCP control will update the corresponding entry in the FF array.

[0160] Table 3 lists the fields in each entry. Some fields are used only by specific event categories, while some fields are used in all categories:

[0161]

[0162]

[0163] Table 3

[0164] This table is similar to Table 2, but includes additional fields and some fields are defined differently. The merging is done by a merging unit 806 which receives events and updates the corresponding segments in the FF array 808.

[0165] When the CCP completes the algorithm run, the CCP sends an indication to the CCC, which includes the processor ID, the calculated rate, and possibly a request to send an RTT measurement packet. The processor ID input from the CCP is coupled to the CAM, which reads the flow ID corresponding to the processor ID. The CCP then controls the sending of the flow ID, rate, and (optionally) a request to send an RTT packet to the transport pipe.

[0166] In summary, Figure 6 , Figure 7 , Figure 8 and Fig. 9 The example implementation shown queues events, drops some if congested, and distributes events to processors. If no processor is available, events of the same type may be merged, and the merged events are stored in the FF array. The CAM is used to quickly locate a processor based on the flow label. Each processor has a FSM, and an arbiter selects which event or merged event will be assigned to an available processor.

[0167] As will be understood, by way of example Figure 6 , Figure 8 The structures of the CCC 118 and CCP control 616 shown in and described above. In alternative embodiments, other suitable structures may be used, including, for example, different arbitration schemes, different event discard mechanisms (or CCC units that do not discard events). In some embodiments, there is no type to class mapper, and an FF array entry is assigned to each event type. The various fields of events and merged events may be different and include different fields. In an embodiment, the CCP may use the flow ID as part of its context and, therefore, send the flow ID directly to the transport pipeline.

[0168] exist Figure 1 , Figure 2 , Figure 6 , Figure 8 and Fig. 9 The configuration of the NIC shown in the Figures (including its units and subunits) is an example configuration depicted purely for the purpose of conceptual clarity. Any other suitable configuration may be used in alternative embodiments. The different NIC elements may be implemented using appropriate hardware, such as software in one or more application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs), or a combination of hardware and software elements.

[0169] CCP 116 typically includes a programmable processor that is programmed with software to perform the functions described herein. The software may be downloaded to the processor in electronic form over a network, for example or possibly, alternatively or additionally provided and / or stored on non-transitory tangible media, such as magnetic, optical, or electronic memory.

[0170] It will therefore be appreciated that the above embodiments have been cited by way of example and that the present invention is not limited to what has been specifically shown and described above. On the contrary. The scope of the present invention includes combinations and sub-combinations of the various features described above as well as variations and modifications thereof which would occur to a person skilled in the art upon reading the foregoing description and which are not disclosed in the prior art. Documents incorporated by reference into this patent application shall be deemed to be an integral part of this application, except that any term is defined in these incorporated documents in a manner that conflicts with an explicit or implicit definition in this specification, only the definitions in this specification shall be considered.

Claims

1. A network adapter for congestion control in a packet communication network, comprising: a receive pipeline configured to receive packets from a network and process the received packets; a transmission pipe configured to transmit packets to the network; hardware-implemented circuitry configured to derive a multi-field entry representing a congestion control event from at least some packets transmitted to the network and at least some packets received from the network; as well as A congestion control programmable processor is configured to receive the multi-field entry from the hardware implemented circuit by software and calculate a transmission rate of the packets transmitted by the transmission pipe to the network in response to the multi-field entry.

2. A network adapter according to claim 1, and comprising a direct hardware-implemented point-to-point interface configured to transmit at least some of the multi-field entries representing congestion control events from the hardware-implemented circuitry to the congestion control programmable processor without operating system calls.

3. The network adapter of claim 1 , wherein the hardware-implemented circuitry comprises an event queue configured to queue the multi-field entry representing the congestion control event, and circuitry configured to pre-process the queued multi-field entry representing the congestion control event.

4. The network adapter of claim 3 , wherein the hardware-implemented circuitry is configured to discard one or more of the queued multi-field entries representing congestion control events and to provide only the multi-field entries representing congestion control events that have not been discarded to the congestion control programmable processor.

5. The network adapter of claim 3, wherein the hardware-implemented circuit is configured to merge two or more of the queued multi-field entries representing congestion control events and provide the merged multi-field entries representing congestion control events to the congestion control programmable processor.

6. The network adapter according to claim 1, wherein the congestion control programmable processor supports an application program interface for receiving a user-defined congestion control software code and calculating the transmission rate by running the congestion control software code.

7. The network adapter of claim 1 , wherein the hardware-implemented circuitry is further configured to transmit a first round trip time packet through the transmit pipe, and receive a second round trip time packet sent from a peer network adapter through the receive pipe in response to the first round trip time packet, And wherein the congestion control programmable processor is configured to estimate a round trip propagation time between the network adapter and the peer network adapter based on the first round trip time packet and the second round trip time packet, and calculate the transmission rate based on the round trip propagation time.

8. A method for congestion control in a packet communication network, comprising: Using the receive pipe of the network adapter, receive packets from the network and process the received packets; transmitting the packet to the network using a transmission pipe of the network adapter; deriving, using hardware implemented circuitry in the network adapter, a multi-field entry representing a congestion control event from at least some packets transmitted to the network and at least some packets received from the network; as well as Using a congestion control programmable processor programmed by software in the network adapter, the multi-field entry representing the congestion control event is received from the hardware-implemented circuit, and a transmission rate of the packets transmitted by the transmission pipe to the network is calculated in response to the multi-field entry representing the congestion control event.

9. The method of claim 8, and comprising transmitting at least some of said multi-field entries representing congestion control events from said hardware-implemented circuitry to said congestion-controlled programmable processor via a direct hardware-implemented point-to-point interface without operating system calls.

10. The method of claim 8, and comprising queuing, in the hardware implemented circuitry, the multi-field entry representing a congestion control event in an event queue and pre-processing the queued multi-field entry representing a congestion control event.

11. The method of claim 10, wherein preprocessing the queued multi-field entries representing congestion control events comprises discarding one or more of the queued multi-field entries representing congestion control events, and providing only the multi-field entries representing congestion control events that have not been discarded to the congestion control programmable processor.

12. The method of claim 10, wherein preprocessing the queued multi-field entries representing congestion control events comprises merging two or more of the queued multi-field entries representing congestion control events and providing the merged multi-field entries representing congestion control events to the congestion control programmable processor.

13. The method of claim 8, wherein calculating the transmission rate comprises using an application programming interface to receive a user-defined congestion control software code, and calculating the transmission rate by running the congestion control software code.

14. The method according to claim 8, further comprising transmitting, using the hardware implemented circuitry, a first round trip time packet through the transmit pipe and receiving, in response to the first round trip time packet, a second round trip time packet sent from a peer network adapter through the receive pipe, and estimating, using the congestion control programmable processor, a round trip propagation time between the network adapter and the peer network adapter based on the first round trip time packet and the second round trip time packet, Calculating the transmission rate includes calculating the transmission rate based on the round-trip propagation time.

Images