[0001] 本发明总体上涉及分组通信网络，尤其涉及用于这种网络中的拥塞控制的方法和系统。

[0002] 通信系统中分组流量的拥塞管理非常重要，这是因为拥塞控制不佳可能会严重影响系统性能。

[0003] 业界使用了一些拥塞控制技术，例如，Almeida和Belo在1999年11月21日至24日召开的第10届IEEE局域网和城域网研讨会上的“Explicit rate congestion control with binary notifications(带有二进制通知的显式速率拥塞控制)”描述了用于分组交换网络的基于速率的源自适应算法，在该算法中，将二进制通知发送到源，以反映源速率和估计的公平速率之间的正或负差，并基于这些通知，源增加或减少传输速率。

[0004] 互联网工程任务组(IETF)RFC 3168在2001年9月发表的名称为“The Addition of Explicit Congestion Notification(ECN)to IP(将显式拥塞通知(ECN)添加到IP)”规定了将ECN(显式拥塞通知)并入TCP和IP，包括在IP报头中两位的ECN使用。

[0025] 总览

[0026] 在1974年引入了传输控制协议(TCP)，但其拥塞控制(CC)算法不断演进。响应于源收到的拥塞通知，CC算法会更改来自传输分组的源(例如，源节点中的网络适配器)的分组的传输速率。拥塞通知通常会添加到分组流中(作为单独的分组或作为现有分组的附加信息)。当分组到达其目的地时(例如，目的地节点中的网络适配器)，目的地将拥塞通知发送回源，这可以响应于该通知而降低传输速率(或者如果没有接收到拥塞通知则提高速率)。

[0027] 已经(并且仍然)提出了许多CC算法，其关于响应于拥塞通知设置传输速率(例如，参见美国专利7,000,025)。响应于与相同流的分组有关的拥塞通知，该算法通常是面向流的并且每个分组流的速率是独立控制的。

[0028] 拥塞控制(CC)算法通常由运行在主机处理器上的软件或专用硬件执行。在主机上实施软件有一些主要缺点。首先，主机软件的实现通常表现出较长的延迟，这是由处理拥塞通知所需的上下文切换引起的；其次，主机软件的实现会消耗大量的CPU资源；最后，由主机软件执行的算法要求网络适配器和主机之间通过总线进行通信。另一方面，软件实现通常是灵活的，允许轻松地适应新的CC算法和改变网络配置，而硬件实现则趋于僵化且难以修改。

[0029] 根据本文所公开的本发明的实施方式提供了具有灵活且快速的拥塞控制的网络适配器。(为了清楚起见，以下描述主要是指网络接口控制器(NIC)。然而，所公开的技术绝不限于以太网NIC；在根据本发明的实施方式中，可以使用任何其他合适的网络适配器，包括例如无限带宽 主机通道适配器(HCA))。

[0030] 在一些实施方式中，NIC包括拥塞控制电路(以下称为“CCC”)和紧密耦合至通信端口的专用拥塞控制可编程处理器(“CCP”，也称为“处理器”)。响应于网络的流量负载，处理器可以限制(减少或增加)分组的传输速率。在实施方式中，NIC被配置为发送、返回和接收往返延迟(RTT)测量分组，其对于设置传输速率(将在下面进行说明)可能有用。

[0031] NIC通常包括一个或多个入口端口，其从网络接收分组并将分组发送到输入队列；和一个或多个出口端口，其从输出队列接收分组并将分组发送到网络。在下面的描述中，将入口端口和输入队列的聚合称为接收管道，并将输出队列和出口端口聚合为传输管道。

[0032] 在一个实施方式中，CCC包括事件队列，其被配置为接收分别与分组发送和接收有关的TX通知和RX通知，并将事件通知发送给CCP。CCC通常会接收已发送分组的每个预定义突发的TX通知以及以下接收到的分组的RX通知：正和负确认(ACK和NACK)分组；拥塞通知分组(响应于所发送的分组由对等网络适配器发送回的分组)；和返回的RTT测量分组。

[0033] 在一些实施方式中，为了避免事件队列中的拥塞，CCC被配置为响应于队列的占用(不要将此拥塞与网络中的拥塞混淆)丢弃(丢掉)某些事件。

[0034] 在下面的一些示例实施方式中，将参考基于融合以太网(RoCE)的远程直接存储器访问(RDMA)；然而，本文公开的技术不限于RoCE，并且可以在任何合适的网络配置中使用。

[0035] 根据一些实施方式，事件队列中存储的事件类型包括：

[0036] 1.TX-发送分组的突发；

[0037] 2.CNP-接收拥塞通知分组(CNP)；

[0038] 3.NACK-接收NACK；

[0039] 4.ACK-接收ACK；

[0040] 5.RTT-接收对往返延迟(RTT)测量分组的响应分组(将在下面进行描述)；和[0041] 6.主机注入事件(将在下面描述)。

[0042] 在一些实施方式中，在CCC队列中通过包括事件类型字段、时间戳字段、序列号字段、流标识字段、表示Tx事件的已发送字节数的字段以及用于其他RTT接收事件时间戳的字段的条目表示事件。

[0043] 在根据本发明的一些实施方式中，除了由Tx管道和Rx管道生成的事件之外，CC事件还包括固件生成的事件，其可以由NIC的用户定义并且提供算法灵活性。

[0044] 在根据本发明的一些实施方式中，CCC包括仲裁器(例如，轮询)，其从事件队列或固件事件中选择要处理的事件。在一些实施方式中，事件类型的数目可以大于CCC可以处理的事件类型的数目，并且可以采用映射，该映射将多于一个事件类型映射到相同的“事件类别”。

[0045] 在根据本发明的一些实施方式中，CCC还包括CCP控制单元(为简便起见，也简称为“CCP控制”)，其被配置为合并CC事件并提交事件并将事件合并到CCP中作为CCP执行的CC算法的输入。在一个实施方式中，CCP控制包括内容可寻址存储器(CAM)，其从拥塞队列接收拥塞事件。CAM被配置为将拥塞事件的流索引与已经分配给CCP处理器的流索引进行比较(存储在CAM中的索引数不大于CCP中的处理器数)，并指向流索引匹配的处理器；或者如果没有找到匹配，则指示“没有匹配”。

[0046] 在各实施方式中，CCP控制进一步包括CCQ片段(每个CCP处理器一个片段)和片段仲裁器，其中每个片段包括有限状态机(FSM)，FSM包括空闲状态、忙碌状态和仲裁状态。从空闲状态开始，当CCQ片段接收到事件时，CCQ片段进入仲裁状态；片段仲裁器决定哪个处于仲裁状态的片段将激活不忙碌的CCP处理器；然后，仲裁器选择的CCQ片段进入忙碌状态，当对应的处理器发出信号通知完成时，返回空闲状态(如下文所述，CCQ片段包括附加状态以支持合并)。在一个实施方式中，CCP控制会将片段仲裁器选择的处理器的索引、对应的流索引和可选的流索引的哈希发送到CCP。

[0047] 在一些实施方式中，当CCP处理器更新速率和/或请求RTT测量时，CCP发送速率和具有处理器ID的请求；CCP控制被配置为(从CAM)读取与处理器ID相对应的流标签，并将具有更新速率和/或RTT请求的流标签发送至传输管道。

[0048] 合并

[0049] 在一些实施方式中，为了提高性能，CCP控制包括合并电路，该合并电路被配置为将对应于相同流和相同事件类别的多个拥塞事件压缩为单个“合并事件”。当将此类合并事件分配给处理器时，处理器将处理合并事件，而不是单独处理每个原始事件。由于需要较少的上下文切换(与将新任务分配给处理器相关联)，因此提高了拥塞处理的效率。此外，通过合并，避免了其中对应于第一流并且正在等待处理器的事件阻止对应于其他流的事件的情况。

[0050] 在一个实施方式中，CCP控制还包括合并单元和FF阵列。对于CCP的每个处理器和每个事件类别，FF阵列均包括条目，其中存储了与同一处理器和类别相对应的所有合并事件的累积数据。当接收到新事件时，合并单元将更新FF阵列中的相应条目。例如，FF阵列条目包括发送字节字段，该字段对传输管道生成的发送分组事件中的字节数进行计数。当CCC接收到新的发送分组事件时，合并单元将相应地增加对应FF阵列条目的发送字节字段。在另一个示例中，每个FF阵列条目包括第一序列号(SN)字段和最后SN字段。当第一事件合并时，事件的SN存储在对应FF阵列条目的第一SN字段和最后SN字段中；当进一步的事件合并到同一FF阵列条目中时，将仅更新最后SN字段。

[0051] 在实施方式中，每个CCQ片段还包括更多工作状态，当新事件合并到现有FF阵列条目中时，相应的CCQ片段将进入更多工作状态；当对应处理器发出完成信号时，CCQ片段将重新进入仲裁状态，请求CCP处理器。

[0052] 在一些实施方式中，固件可以重写CCP处理器，每个CCP片段都包括其他状态，以支持固件重写和固件释放。

[0053] CCP

[0054] 在各实施方式中，CCP运行的CC算法包括多个并发进程，其中每个进程在单个分组流中控制拥塞。每个进程被配置为接收与相应流有关的事件，更新速率(并可能请求RTT测量)，然后暂停直到接收到下一个事件。为了允许有限数目的处理器执行，每个进程都在存储器中分配了上下文；可以通过存储上下文来暂停进程，并通过读取存储的上下文来恢复进程(因为可能的上下文数目可能很大，与不活动的流相关的上下文通常存储在较慢的存储器中，并在需要时由处理器读取)。

[0055] 根据一些实施方式，CCP包括多个独立的处理器，CCC发送给CCP进行处理的事件将分配给不忙碌的处理器。被分配来处理事件的处理器读取相应的上下文，然后运行该进程，可能会更改流的传输速率和/或请求RTT测量，最后存储更新的上下文，为处理下一个事件进行准备。

[0056] RTT

[0057] 在根据本发明的实施方式中，分组往返延迟(RTT)的可靠测量是CC算法的重要参数。RTT测量通常通过计算从发送分组到接收相应ACK的时间差来完成；但是，这种测量技术并不准确，因为ACK是由处理器启动的，而RTT测量将包括软件响应所花费的时间。

[0058] 根据本发明的一些实施方式支持RTT测量分组，该RTT测量分组从发送方网络接口控制器(NIC)发送到接收方NIC，该接收方NIC将该分组返回给发送方NIC。发送方NIC将第一时间戳添加到发送分组中；当接收到分组时，接收方NIC将第二时间戳添加到分组，将分组路由回发送方NIC，并当发送回分组时添加第三时间戳。然后，发送方NIC通过观察三个时间戳(以及返回分组到达的时间)，可以准确地计算RTT，并将其分为多个段，包括从发送方NIC到接收方NIC的时间、接收方NIC内的时间、从接收方NIC到发送方NIC(返回分组)的时间。

[0059] 系统描述

[0060] 图1是示意性地描述了根据本发明的实施方式的具有拥塞缓解的RoCE架构100的框图。传输NIC 102通过网络104将分组传输到接收NIC106。(应注意，传输NIC和接收NIC均配置为传输和接收分组；以上术语“传输”和“接收”是指缓解拥塞的方向)。

[0061] 传输NIC 102包括传输(TX)管道108，其对NIC传输的分组进行排队和仲裁，并将分组发送到网络104。根据图1所示的示例实施方式网络包括交换机110，当拥塞时其用显式拥塞指示(ECN)标记传输NIC发送的分组。

[0062] 接收NIC 106将返回分组发送回传输NIC，包括用于拥塞控制的分组(在图1中用虚线表示)，例如CNP分组、ACK/NACK分组和RTT测量分组(如下所述)。当接收NIC接收到具有ECN指示的分组时，接收NIC将CNP分组发送回发送NIC。

[0063] 传输NIC 102还包括接收(RX)管道112，其接收来自网络的输入分组，以及拥塞控制单元114。

[0064] 拥塞控制114被配置为执行拥塞控制算法并减轻RoCE传输路径中的拥塞。拥塞控制包括被配置为运行拥塞控制算法的拥塞控制处理器(CCP)116以及拥塞控制电路(CCC)118，其被配置为将拥塞事件发送到CCP。

[0065] 当传输管道108发送分组突发时，CCC 118接收Tx事件，并且当接收管道112接收拥塞控制分组时，CCC 118接收Rx事件。(接收到的拥塞控制分组可以包括，例如，响应于传输的分组而接收到的ACK和NACK，接收NIC响应于接收到ECN标记的分组而生成的CNP分组以及RTT测量分组。)

[0066] CCC将事件排队，并通过硬件实现的直接点对点接口120将至少一些事件发送给CCP。在本上下文中，术语“直接点对点接口”是指不涉及通过总线、中断或任何其他操作系统调用进行通信的接口。CCP处理这些事件并运行拥塞控制算法以计算其他分组所需的传输速率，然后将该速率通知传输管道108，并且可选地请求传输管道发送RTT测量分组。

[0067] 在一些实施方式中，CCP针对每个分组流单独地运行拥塞控制算法，并且针对每个流单独地确定传输速率。

[0068] 在根据本发明的实施方式中，CCC和CCP之间的通信不涉及操作系统调用-CCP发出准备处理事件的信号(例如，通过断言专用信号)，然后在CCC驱动的输入总线上读取事件。

[0069] 因此，根据图1的示例实施方式，拥塞事件由专用电路排队，并提交给运行拥塞控制算法的专用处理器，相应地修改传输速率。与运行算法相关的开销很小，并且保留了更改拥塞控制算法的灵活性。

[0070] 如将意识到的，RoCE体系结构100的配置是示例配置，其被描绘纯粹出于概念上的清楚。在本发明的替代实施方式中可以使用其他合适的配置。例如。代替(或除了)RoCE，该架构可以是TCP和/或聚合的非易失性存储器(NVM)存储(例如，超聚合的NVM-f)。CCC 118接收到的拥塞事件可以通过附加的硬件或软件进行预排序；传输管道发送分组的速率可以由CCP 116和传输NIC 102的其他算法共同控制。

[0071] 图2是示意性地示出了根据本发明实施方式的传输NIC 102的结构的框图200。(为清楚起见，应注意，传输NIC和接收NIC可以是相同或相似的，但是当NIC用作传输NIC时，激活拥塞控制电路。此外，当两个方向都拥塞时，可以将相同的NIC同时配置为传输NIC和接收NIC。)

[0072] 传输NIC包括传输管道108、接收管道112、拥塞控制处理器(CCP)116和拥塞控制电路(CCC)118(上面的单元参考图1进行了描述)。

[0073] 传输管道108发送与NIC传输给CCC的分组有关的通知。在一个实施方式中，传输管道发送与所传输的分组的突发有关的通知；在其他实施方式中，仅发送与预定义子集有关(例如，关于通过预定义端口流出的分组)的通知。

[0074] 接收管道112向CCC发送拥塞控制通知。在图2的示例实施方式中，这样的通知包括由接收NIC(例如，图1的NIC 106)向发送NIC发送回的拥塞通知分组(CNP)、ACK分组、NACK分组和RTT测量分组。在一些实施方式中，CCC仅接收一些通知；例如，根据接收通知的入口端口。

[0075] CCC将来自接收和传输管道的通知排队，对事件进行预处理，然后通过直接的点对点接口120将拥塞控制(CC)事件转发到CCP。在根据本发明的实施方式中，CCC输出的CC事件通常与CCC接收到的CC事件不相同；相反，可以对输出事件进行稀释、合并和转换，如下所述。

[0076] CCP 116运行CC算法。CCC输出的CC事件输入到CCP。根据算法，CCP有时会更改传输速率。有时，CCP可能会请求传输管道发送RTT测量分组。

[0077] CCP 116包括处理器场202，其包括多个处理器，以及CCP上下文存储204(通常是RAM)。根据实施方式，CC算法单独针对分组的每个流运行；每当从CCC接收到了新事件，该算法响应于新事件将重新运行并更新相应流的传输速率(如果每个流都没有遇到上下文，则处理器从初始上下文开始)。在图2所示的示例实施方式中，在CCP上下文存储中为每个流分配了上下文；上下文包括执行停止后继续执行CC算法所需的所有数据。

[0078] 当从CCC接收到新的CC事件时，该事件已分配给处理器场的处理器之一。然后，处理器读取与事件的流相对应的上下文并继续运行CC算法，响应于新事件更新速率计算。当处理器完成更新速率的计算时，处理器将速率发送给传输管道108，将更新的上下文存储在CCP上下文存储204中，并且停止(或直接开始处理新事件)。

[0079] 由于可能的流的数目很大，将所有上下文存储在CCP上下文存储204中可能不切实际。而是，一些活动较少的流的上下文可以存储在更大(和更慢)的存储器中，并在需要时加载到CCP上下文存储中。在一些实施方式中，CCP上下文存储204包括高速缓存存储器，当高速缓存未命中时从主存储器更新。

[0080] 综上所述，CCC从传输管道接收与传输的分组有关的通知，以及与来自接收管道的拥塞控制分组有关的通知。CCC将事件排队，并将预处理的事件输出到CCP。CCP包括多个处理器和上下文存储；获得事件的每个处理器读取相应的上下文(即与相同分组流有关的上下文)，并运行CC算法。由于RTT的值可能是算法需要的，因此处理器可能会请求传输RTT测量分组。处理器更新传输速率，完成后将其上下文存储在上下文存储中。

[0081] CCC和CCP之间的接口非常有效，因为不需要操作系统调用；上下文读和写通常在1至4个时钟周期内完成。

[0082] 可以理解，通过示例的方式引用了图2所示的CCC 118和CCP116的结构。根据所公开的技术的拥塞控制电路和拥塞控制处理器不限于以上描述。在替代实施方式中，例如，可以监视更多事件，例如每个接收到的分组时的Rx事件。在一些实施方式中，CCC可以被嵌入在传输管道内。在其他实施方式中，服务器场中的每个处理器可以具有其自己的上下文存储；在其他实施方式中，每个处理器可以具有用于频繁使用的上下文的高速缓存存储器。

[0083] 图3A是示意性地示出根据本发明的实施方式的拥塞控制场景中接收CNP的时序图。时序图包括CCC时间轴300和CCP时间轴302，其分别示出了发生在CCC和CCP(图1中的118和116)中的事件。

[0084] 应该注意的是，时序图仅示出了与特定流有关的分组；可以同时接收和处理与其他流有关的分组，但是为了清楚起见在图3A中未示出。

[0085] 当CCC将发送事件306发送到CCP时，时序图开始(在顶部)。然后，CCP的处理器将进入CC算法执行周期304。在图3A的示例实施方式中，传输速率保持不变。接下来，CCC再发送三个发送突发事件306，并且作为响应，CCP再运行CC算法3次(可能会收集统计信息，但不更改速率)。发送突发事件306之间的时间间隔是固定的T1，因为传输速率不变。

[0086] 现在，传输NIC和接收NIC之间的交换机变得拥塞，并用ECN标记分组。接收NIC将CNP分组路由回传输NIC，其中它由接收管道接收并通过信号发送给CCC。作为响应，CCC将接收CNP事件308发送给CCP。CCP将再次进入CC算法执行周期304，但是这次算法响应于CNP将计算较低的传输速率。然后，CCP将新的传输速率通知310(其可能低于先前的速率)发送到传输管道，作为响应，将增加分组传输之间的时间间隔。传输管道将以较低的速率发送后续分组(并且CCC将向CCP发送相应的发送分组事件)，其中传输之间的距离为T2(T2>T1)。

[0087] 请注意，在上面的示例中速率的变化是即时的并在收到CNP之后的下一个突发处发生。在实施方式中，CNP可能会接收迟到，并且在T1之后仍继续传输下一个分组；新速率将在后续分组之一中生效。

[0088] 图3B是示意性地示出了根据本发明实施方式的在拥塞控制场景中开始新的分组流的时序图。类似于图3A，该时序图包括CCC时间轴300和CCP时间轴302；并且仅显示与感兴趣的流有关的事件。

[0089] 当CCC向CCP发送发送突发事件314时，时序图开始。相应的上下文在CCP上下文存储204(图2)中不存在-它是新的或已在上下文存储中被更活跃的上下文替换。接下来，CCP向传输管道发送指示316，其中CCP将速率设置为预设的默认速率，并要求CCC发送RTT测量分组。

[0090] 现在，传输管道发送第一突发。在突发末尾，传输管道添加RTT请求分组。CCC在T1之后收到具有RTT发送指示的Tx事件316。CCP运行CC算法，但是缺少新信息，不会更改传输速率。

[0091] 如下所述，RTT测量分组通过网络行进到接收NIC，其添加了时间戳，并将分组引导回发送NIC。当发送NIC接收到返回的RTT测量分组时，CCC将RTT响应接收到的通知320发送给CCP。CCP重新输入CC算法执行304，并且响应于RTT测量，计算传输速率的新值。在图3B所示的示例实施方式中，速率应比默认更快(例如，如果RTT测量检测到短的往返延迟)，并且CCP向传输管道发送新的传输速率命令322，其值高于默认速率。传输管道以较高的速率发送下一个分组(并且CCP将发送相应的发送分组通知)，其中延迟为T2(T2＜T1)。

[0092] 综上所述，当新的流(或上下文存储中没有上下文的流)开始时，传输队列以默认速率发送分组；CCP请求传输管道启动RTT测量。当RTT测量响应分组到达时，该算法计算所需的传输速率并相应地更新传输管道。

[0093] 如将意识到的，如图3A、图3B所示以及如上所述，在传输NIC中发生的事件的顺序通过示例的方式引用。根据所公开的技术的传输NIC和CC算法不限于以上描述。在替代实施方式中，例如，可以通过CNP事件、RTT测量、ACK和NACK分组的组合来设置传输速率；在其他实施方式中，当没有接收到事件时，速率可以改变，例如默认情况下，速率可能会增加以获得更好的性能。在一些实施方式中，当计算新速率时，CCP将逐步改变速率；例如，为了降低速率，在接下来的每个分组中CCP可以将速率乘以小于一的因子。

[0094] RTT测量

[0095] 例如RoCE的网络配置中RTT(往返延迟)的值可能是CC算法的重要参数。本文公开的根据本发明的实施方式提供了一种有效且准确的方法来测量RTT，即在传输NIC和接收NIC之间的往返传播时间。传输NIC被配置为发送具有时间戳的RTT测量分组，并且接收NIC被配置为添加时间戳并将测量分组返回到传输NIC。

[0096] 图4是示意性地示出了根据本发明实施方式的网络中的RTT测量流的框图。传输NIC102发送RTT测量分组402，其包括第一时间戳(T1)404，指示该分组被传输的时间。然后，该分组横穿网络104，到达接收NIC106。接收NIC将分组路由回发送方，当NIC接收到分组时添加第二时间戳(T2)406，并且当NIC发送返回的分组时添加第三时间戳(T3)408。根据实施方式，接收NIC时的RTT响应由软件快速执行而没有调度或排队。

[0097] 当返回的分组到达传输NIC时，传输NIC可以得出往返时间延迟的三个分量：

[0098] 从传输NIC到接收NIC的时间延迟——T2-T1；

[0099] 接收NIC中从入口端口到出口端口的时间延迟——T3-T2；

[0100] 从接收NIC到传输NIC的时间——在传输NIC处接收到分组的时间与T3之间的差。

[0101] 应该注意的是，RTT分组可能具有未显示的其他字段，例如传输NIC和/或接收NIC的ID、入口端口和出口端口等。

[0102] 因此，根据本发明的实施方式，假设接收NIC支持RTT测量，则传输NIC可以被配置为发起RTT测量。然后，可以将测得的RTT用作传输NIC可以运行的CC算法的参数。

[0103] 如将意识到的，通过示例引用如图4所示的RTT测量分组的结构。根据所公开的技术的RTT测量分组不限于以上描述。在替代实施方式中，可以添加更多的时间戳以及其他字段。在实施方式中，接收NIC可能会向RTT测量分组添加时间差而不是绝对时间。

[0104] 用户可编程性

[0105] 在根据本发明的实施方式中，CCP运行的CC算法可能会有时由NIC用户更改，包括在现场进行的更改。

[0106] 图5是示意性地描述了根据本发明的实施方式的将由CCP运行的CC算法的开发的流程图。该流程由用户(通常是程序员)执行。

[0107] 该流程开始于编写C代码步骤502，其中用户以C代码编写CC算法。用户必须遵守一些规则，像固定的上下文结构、固定的输入API和输出API。然后，用户在编译步骤504中使用例如LLVM中间表示(LLVM-IR)编译器504编译C代码。编译器的输出是目标代码506。

[0108] 然后，用户可以运行模拟器508以检查算法在网络中将如何执行。在模拟之后(或代替模拟)，用户执行编程闪存步骤510，其中用户使用由编译器生成的代码对闪存(或另一类型的NVM)编程。在图5的示例实施方式中，闪存受到保护，并且用户必须提供安全密钥512以使得能够向闪存写入。最后，在测试/部署步骤514中，用户测试该算法，并且如果良好，则在NIC单元中部署CC代码。

[0109] 可以理解，通过示例引用图5所示的并在上文中描述的CC开发流程。在替代实施方式中，可以使用其他合适的开发流程，包括例如Python代码编程和其他编译器的使用。

[0110] 图6是示意性地示出了根据本发明实施方式的拥塞控制电路(CCC)118的结构的框图。CCC包括：

[0111] 1.Tx-事件FIFO 602，其被配置为临时存储FIFO从传输管道108(图1)接收的Tx事件；

[0112] 2.Rx-事件FIFO 604，其被配置为临时存储FIFO从接收管道112接收的Rx CC事件；

[0113] 3.传输事件加权随机早期丢失(WRED)单元606和接收事件WRED 608，其被配置为分别从Tx-FIFO和Rx-FIFO中随机稀释事件(基于每个事件类型)；

[0114] 4.固件事件单元610，其被配置为将FW生成的CC事件(例如，CC管理事件)输入到CCP；

[0115] 5.循环选择器612，其被配置为从Tx事件FIFO、Rx事件FIFO或FW事件单元中选择CC事件；

[0116] 6.类型到类别映射器614，其被配置为将事件类型映射到事件类别；

[0117] 7.CCP控制单元616；以及

[0118] 8.Tx速率更新FIFO 618，其被配置为临时存储Tx流的新速率。

[0119] 事件类型

[0120] 根据图6所示的示例实施方式，CC从传输管道和接收管道接收的事件分为七种类型：

[0121] 1.TX-传输管道已发送分组或分组的突发；

[0122] 2.CNP-已从接收NIC接收到拥塞通知分组；

[0123] 3.NACK-已接收到隐式或显式(例如，失序(OOS))NACK；

[0124] 4.ACK-已接收到ACK；

[0125] 5.RTT-已接收到RTT测量分组(响应于传输NIC已经发送的RTT测量分组由接收NIC发送)；

[0126] 6.RTT发送事件-RTT分组已由传输管道发送(此事件实际上是带有RTT发送指示的Tx事件)；

[0127] 7.FW事件-FW生成的CC事件。

[0128] 来自传输管道108(图1)的Tx事件进入Tx-事件FIFO 602。每个事件包括事件数据描述符，其除了事件类型还包括其他信息(将在下面描述)；例如流号、时间戳等。为了避免FIFO溢出，WRED 606在FIFO填满时随机丢弃(丢掉)事件(将在下面参考图7进一步描述)。以类似的方式，来自接收管道112的Rx CC事件进入Rx-事件FIFO 604，其受WRED 608保护，以防溢出。

[0129] FW事件单元610被配置为响应于FW指令生成CC事件，CC事件也由CCP执行。根据图6所示的示例实施方式，FW事件单元生成的事件不具有FIFO，并且CCP必须在接收到后续的FW事件之前处理FW事件。

[0130] 循环选择单元612从Tx事件FIFO、Rx事件FIFO和FW事件单元中顺序选择CC事件，并将所选事件转发给事件类型到类别映射器614。在图6所示的示例实施方式中，CCP处理五个事件类别，而CC可以接收多达七个事件类型。事件类型到类别映射器包括映射表，该映射表将多于一个类型映射到同一类别。该表由FW编程。

[0131] 表1描述了映射表的结构：Tx分组发送事件 类别ID(3位)
Tx RTT请求事件 类别ID(3位)
CNP事件 类别ID(3位)
NACK事件 类别ID(3位)
ACK事件 类别ID(3位)
RTT事件 类别ID(3位)
FW事件 类别ID(3位)
表1

[0132] 类型到类别映射器614将包括事件类别的事件指示发送到CCP控制器616。对于每个事件，类型到类别映射器发送与该事件有关的信息。表2列出了类型到类别映射器随每个事件发送的信息(一些更多信息(其在以下未指出)可以在Tx事件和FW事件中发送)：表2

[0133] CCP控制合并事件组并激活CCP以处理合并的事件(下面将参考图8描述CCP控制的结构)。当完成CCP处理器时，CCP控制616进一步从CCP接收指示，并接收由CCP设置的更新的传输速率以及发送RTT测量分组的请求。然后，CCP控制将更新的速率发送到Tx速率更新FIFO 618，其临时存储新速率并当传输管道准备好更新速率时将该速率发送到传输管道。CCP控制还将任何RTT测量请求发送到传输管道。

[0134] 图7是示意性地示出了根据本发明的实施方式的WRED 606和608(图6)的操作的曲线图700。可以为每种事件类型定义不同的WRED功能。该曲线图包括水平轴702，其表示队列占用率；垂直轴704，其表示事件被丢弃的概率；以及曲线706，其表示丢弃概率函数。可以为每种事件类型分别设置的两个参数定义了WRED功能：第一阈值TH1和第二阈值TH2。

[0135] 将事件丢弃概率定义为队列占用率的函数，如下所示：

[0136] P＝(占用率

[0137] (占用率<＝TH2)？(占用率-TH1)*斜率：

[0138] (TH2-TH1)*斜率；

[0139] (斜率＝1/(TH2-TH1))

[0140] 通过仔细编程每种事件类型的参数，用户可以保证FIFO不会溢出，并且当队列占用率增加时，不太重要的事件类型将更有可能被丢弃。

[0141] 应当理解，通过示例引用图7中示出的并在上文中描述的曲线图700。在替代实施方式中，可以使用各种合适的概率曲线图，包括例如具有三个以上分片的分段线性曲线图；永远不会达到100％丢弃率的曲线图和弯曲状曲线图。

[0142] 图8是示意性地示出了根据本发明实施方式的CCP控制616(图6)的结构的框图。CCP控制包括内容可寻址存储器(CAM)800，其被配置为定位哪个处理器(如果有的话)分配给新事件的流程；片段单元802，其包括n个CCQ片段804，其中n是CCP中的处理器的数目；合并单元806，其被配置为合并多个事件；FF阵列808，其存储合并事件；仲裁器810，其选择要分配给处理器的CCQ片段；多路复用器812，其选择与所选择的CCQ片段相对应的流ID；和哈希814，其将哈希密钥添加到所选的流ID。

[0143] 当CCP控制从类型到类别映射器接收到事件时，事件的流ID指向CAM 800和片段802。CAM包括n个条目，其中n是处理器的数目。对于每个条目，流ID存储在搜索字段中，并且当在CAM输入处断言流ID时，CAM将搜索该ID。如果流ID存储在CAM中，则CAM将指示相应的处理器ID；如果未存储该流ID，则CAM将输出随机处理器ID(未分配给任何其他流ID)并指示“不匹配”(使用CAM术语，当与输入流ID匹配时发生“命中”，而当不匹配时发生“未命中”)。
CAM 800还被配置为通过指定处理器ID并执行读取或写入操作来允许直接访问存储的流ID。

[0144] CAM中的命中指示CCQ片段之一被分配给传入事件。新事件将定向到相应的CCQ片段，其将请求仲裁者分配CCP的处理器来处理事件(该请求可能会延迟，如下文所述)。如果没有命中，则CCP等待直到存在至少一个空闲处理器，然后随机选择其中一个空闲处理器；相应的CCQ片段将被分配给传入事件。在那种情况下，CAM将流ID写入与CAM生成的随机处理器ID相对应的条目的搜索字段中，使得对同一流的其他事件的搜索将导致“命中”。

[0145] 现在将描述片段802，其包括CCQ片段804，每个CCP处理器一个片段。每个CCQ片段804包括FSM。

[0146] 图9是示意性地示出了根据本发明的实施方式的每个CCQ片段804(图8)的有限状态机(FSM)的状态图900。应当理解，为清楚起见，简化了状态图900，并且省略了一些细节。

[0147] 在重置系统后，FSM处于空闲状态902，等待处理新事件的请求。当接收到新事件时，FSM进入仲裁状态904，其中CCQ片段请求仲裁(来自图8的仲裁器810)。当仲裁者批准该请求时，FSM进入忙碌状态906，其中相应的CCP处理器将使用新事件运行CC算法。当FSM从CCP接收到处理器完成指示(对应于当前处理器)时，如果FSM仍处于“忙碌”状态，则FSM将重新进入空闲状态902。

[0148] 当接收到新事件同时处理器忙于上一个事件时，新事件将合并，并且FSM不应进入空闲状态。就FSM而言，当FSM处于忙碌状态906并且接收到新事件时，FSM进入更多工作A状态908(并且如果接收到其他新事件，则保持在更多工作A状态)。当CC片段接收到处理器完成指示时，FSM将进入仲裁状态904，并将针对希望访问处理器的其他竞争者片段进行重新仲裁。(在一些实施方式中，更多工作状态908是附加机制的简化表示，该附加机制合并了当FSM忙碌时接收到的附加事件；在实施方式中，当FSM处于ARB状态904时也可以接收附加事件。)

[0149] 如上所述，固件可能希望重写CC算法并以软件(即-不是在CCP处理器中)计算速率。FW驱动两个信号-FW重写信号和FW释放，FW重写信号指示FW请求运行CC代码，并且FW释放指示CC事件之间的仲裁可以继续。

[0150] 当FSM处于空闲状态902或处于忙碌状态906并且FW断言FW-重写指示时，FSM将进入FW状态910，等待FW完成。当FW断言FW释放信号时，如果FSM仍处于FW状态，则FSM将进入空闲状态902。

[0151] 当FSM处于固件状态910时，如果新事件被接收(并合并)，则FSM将进入更多工作B状态912(并且如果接收到更多事件，则将保持在更多工作B状态)。如果FSM处于更多工作B状态，并且FW断言FW-释放信号，则FSM将进入仲裁状态904，并且重新仲裁。

[0152] 现在回到图8。仲裁器810确定应将哪个CCQ片段分配给CCP处理器。根据图8所示的示例实施方式，可以一次(例如，每个时钟周期)分配一个处理器。CCQ片段804还被配置为将相应的流ID输出到复用器812，复用器812选择与仲裁器选择的处理器相对应的流ID。然后，CCP控制将处理器ID和流ID都与哈希流ID(其由哈希814生成)一起输出到CCP中的处理器。

[0153] 合并

[0154] FF阵列808包括n个片段(n是CCP中的处理器的数目)。每个FF片段包括五个条目，每个类别一个。每个条目包括事件数据。当CCP控制616接收到事件，并且分配为处理与相应流有关的事件的处理器忙碌时，CCP控制将事件合并到FF数组中的相应条目中。当CCP控制接收到相同流和相同的类别的其他事件时，CCP控制将更新FF数组中的相应条目。

[0155] 表3列出了每个条目中的字段。一些字段仅由特定的事件类别使用，而某些字段则在所有类别中使用：表3

[0156] 该表与表2相似，但是包括其他字段并且某些字段不同地定义。合并由合并单元806完成，合并单元806接收事件并更新FF阵列808中的相应分段。

[0157] 当CCP完成算法运行时，CCP向CCC发送指示，该指示包括处理器ID、计算出的速率以及可能的发送RTT测量分组的请求。从CCP输入的处理器ID耦合到CAM，其读取与处理器ID相对应的流ID。然后，CCP控制向传输管道发送流ID、速率以及(可选)发送RTT分组的请求。

[0158] 综上所述，图6、图7、图8和图9所示的示例实施方式将事件排队，如果拥塞则丢弃其中一些，并将事件分配给处理器。如果没有可用的处理器，则可能合并相同类型的事件，合并的事件存储在FF阵列中。CAM用于根据流标签快速定位处理器。每个处理器都有FSM，并且仲裁器选择哪个事件或合并的事件将分配给可用的处理器。

[0159] 如将理解的，通过示例引用图6、图8中所示的并在上文中描述的CCC 118和CCP控制616的结构。在替代实施方式中，可以使用其他合适的结构，包括，例如，不同的仲裁方案、不同的事件丢弃机制(或不丢弃事件的CCC单元)。在一些实施方式中，不存在类型到类别映射器，并且为每个事件类型分配了FF阵列条目。事件和合并事件的各个字段可能不同，并且包括不同的字段。在实施方式中，CCP可以使用流ID作为其上下文的一部分，并且因此，将流ID直接发送到传输管道。

[0160] 在图1、图2，图6、图8和图9中示出的NIC的配置(包括其单元和子单元)是纯粹出于概念清楚的目的描绘的示例配置。在替代实施方式中可以使用任何其他合适的配置。可以使用适当的硬件，例如在一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)中使用软件或使用硬件和软件元件的结合来实现不同的NIC元件。

[0161] CCP 116通常包括可编程处理器，其用软件编程以执行本文所述的功能。该软件可以电子形式通过网络下载到处理器，例如或可能，替代地或附加地提供和/或存储在非暂时性有形介质上，例如磁性、光学、或电子存储器。

[0162] 因此将意识到，通过示例引用了上述实施方式并且本发明不限于以上已经具体示出和描述的内容。相反。本发明的范围包括上述各种特征的组合和子组合以及本领域技术人员在阅读前述说明后将想到的并且在现有技术中未公开的其变型和修改。通过引用并入本专利申请的文件应被认为是本申请的组成部分，除了在这些并入文件中以与本说明书中明确或隐含的定义相抵触的方式定义任何术语外，应该仅考虑本说明书中的定义。