在高速网卡中实现可编程传输协议.docx

在高速网卡中实现可编程传输协议摘要：数据中心网络协议栈正在转向硬件,以在低延迟和低侬利用率的情况下实现IOOGbPS甚至更高的数据速率。但是，N叫中网络协议栈的硬连线方式扼杀了传输协议的创新。本文通过设计ToniC（一种用于传输逻辑的灵活硬件架构）来实现高速网卡中的可编程传输协议。在IOOGbPS的速率下，传输协议必须每隔几纳秒在NIC上仅使用每个流状态的几千比特生成一个数据段。通过识别跨不同传输协议的传输逻辑的通用模式，我们为传输逻辑设计了一个高效的硬件“模板”，该模板在使用简单的AE1编程的同时可以满足这些约束。基于FPGA的原型系统实验表明,ToniC能够支持多种协议的传输逻辑，并能满足IOOGbPS背靠背128字节数据包的时序要求。也就是说，每隔10ns,我们的原型就会为下游皿流水线的一千多个活动流中的一个生成一个数据段的地址，以便获取和传输数据包。1. 介绍传输协议以及网络协议栈的其余部分传统上都在软件中运行。尽管软件网络协议栈一直在努力提高其性能和效率，但为了跟上当今数据中心的应用程序，软件网络协议栈往往会消耗30-40%的CPU周期。随着数据中心转移到100GbDS以太网上,软件网络协议栈的CPU利用率变得越来越高。因此，多个供应商开发了完全在网卡（NIC）上运行的硬件网络协议栈。但是，在这些NIC上仅实现了两种主要的传输协议，它们都是硬连线方式并且只能由供应商修改。RoCE.R。CE用于远程直接内存访问（RDMA）,使用KQCN43进行拥塞控制，并使用简单的go-back-N策略进行可靠数据传输。TCP.一些供应商将他们选择的TCP变体卸载到NIa以便直接通过套接字API（TCP卸载引擎）使用或启用RDNIA（iWARP）。然而，在过去几十年中提出的用于可靠传输和拥塞控制的无数可能篁法中，这些协议仅使用了一小部分。例如，最近的研究表明，低延迟数据中心网络可以显著受益于接收端驱动的传输协议，这并不是当今硬件堆栈的选择。在微软数据中心部署RoCE网卡的尝试中，运营商需要修改数据传输算法以避免网络中出现活锁，但必须依赖N1C供应商进行更改。己经提出了其他算法来改进RoCE的简单可靠传输算法。多年来，TCP在各种网络中的优化列表证明了传输协议对可编程性的需求。在本文中，我们研究如何实现硬件传输协议可编程化。即使N1C供应商开放了硬件编程接口,在高速硬件中实现传输协议也需要大量的专业知识、时间和精力。为了跟上IOOGbPS的速度，传输协议应该每隔几纳秒生成并传输一个数据包。它需要能够处理超过Iooo个活动流，这在今天的数据中心服务器中是很普遍的。然而，NIC在其片上内存和计算资源的数量方面受到极大的限制。我们认为，高速网卡上的传输协议可以通过编程实现，而不需要让用户接触高速硬件编程的全部复杂性。我们的论点主要基于两个因素：首先，可编程传输逻辑是实现灵活硬件传输协议的关键。传输协议的实现完成了多种功能，例如连接管理、数据缓冲区管理和数据传输。然而，它的核心任务是决定传输哪些数据段（数据传输）和何时传输（拥塞控制），统称为传输逻辑，这也是大多数创新的地方。因此，在高速NIC上实现可编程传输协议的关键是使用户能够修改传输逻辑。其次，可以利用传输逻辑中的通用模式来创建可重用的高速硬件模块。尽管它们在应用级API（例如，TCP的套接字和字节流抽象与RDNIA的基于消息的谓词API）以及连接和数据缓冲区管理方面存在差异，但传输协议有几种共同的模式。例如，不同的传输协议使用不同的算法来检测丢失的数据包。但是，一旦数据包被宣布丢失，可靠传输协议就会将其重传而优先于发送一个新的数据段。另一个例子，在拥塞控制中，给定由控制环路确定的参数（例如，拥塞窗口和速率），只有几种常见的方法来计算流在任何时候可以传输多少字节。这使我们能够为硬件中的传输逻辑设计一个高效的“模板”，可以使用简单的AP1对其编程。基于这些观点，我们设计并开发了Tor1ie,这是一种可编程的硬件架构，可以使用简单的API来实现各种传输协议的传输逻辑，同时支持IOOGbps的数据速率。每个时钟周期,TOniC都会生成下一个数据段的地址进行传输。数据段由下游DMA流水线从内存中提取，并由硬件网络协议栈的其余部分转换为一个完整的数据包（图DoFigure1:Tonicprovidingprogrammab1etransport1ogicinahanwarenetworkstackontheNIC(sender-side).""我们认为Tonic将驻留在NIC上，取代传输协议硬件实现中的硬编码传输逻辑（例如,未来的RDMANIC和TCP卸载引擎）。TOniC为传输逻辑提供了一个统一的可编程架构，与不同传输协议的具体实现如何执行连接和数据缓冲区管理以及它们的应用层AP1无关。然而，我们将以SoCketAP1为例，描述ToniC如何与传输层的其余部分交互（§2）,以及如何将其集成到1irWX内核中以与应用程序进行交互（§5）。我们在约8000行的VeriIOg代码中实现了Tonic原型，并在不到200行代码中实现各种传输协议的传输逻辑，从而证明了ToniC的可编程性。我们还使用FPGA展示了Tonic满足100Mpps的时序，即支持IOOGbps的背靠背128B数据包。也就是说，每隔10ns,ToniC可以生成下游DMA流水线获取和发送一个数据包所需的传输元数据。从生成到传输，单个段地址通过TOniC的延迟约为0.1s,ToniC最多可支持2048个并发流。2. OniC作为传输逻辑本节概述了TOniC如何适应传输层（§2.1）,以及如何克服在高速N1C上实现传输逻辑的挑战（§2.2）。>2.1Tonic如何适应传输层位于应用程序和堆栈其余部分之间的传输层协议执行两个主要功能：连接管理：连接管理包括创建和配置端点（例如，TCP的套接字和RDMA的队列对），并在开始时建立连接，在结束时关闭连接并释放其资源。数据传输：数据传输涉及以段流的形式可靠而高效地将数据从一个端点传输到另一个端点U不同的传输协议为应用程序请求数据传输提供了不同的API：TCP提供了字节流的抽象，应用程序可以连续向该字节流追加数据，而在RDMA中，对队列对的每个“send”调用都会创建单独的工作请求，并被视为单独的消息。此外，在不同的传输协议实现中，管理应用程序的数据缓冲区的具体情况也有所不同。无论如何，传输协议必须将未完成的数据以适合单个数据包的多个数据段形式传输到目的地。确定哪些字节构成下一个数据段以及何时传输它是通过数据传输和拥塞控制算法来完成的，我们统称为传输逻辑并在Tonic中实现。图1显示了Tonic如何适合硬件网络协议栈的高级概述。为了将Tonic与连接管理和应用级AP1的细节分离，连接设置和拆卸需要在ToniC之外运行。Tonic依靠传输层的其余部分为每个已建立的连接提供唯一的标识符（流id）,并使用这些ID显式地添加和删除连接。对于发送端的数据传输，Tonic跟踪未完成的字节数和特定于传输的元数据以实现传输逻辑，即在拥塞控制算法指定的时间为每个流生成下一个数据段的地址。因此，Tonic不需要存储和/或处理实际的数据字节；它依靠传输层的其余部分来管理主机上的数据缓冲区，并在现有连接上有新的数据传输请求时通知它（有关详细信息，请参阅§5）。传输逻辑的接收端主要涉及生成控制信号，如确认，每个数据包的授权令牌或周期性拥塞通知数据包（CNP）,而传输层的其余部分则管理接收数据缓冲区并将接收的数据传输给应用程序。虽然处理接收到的数据可能会相当复杂，但在接收端上生成控制信号通常比发送端上更简单。因此，虽然我们主要关注发送端，但我们重用发送端的模块来实现接收端，仅用于生成每个数据包的累积和选择性ack,并以线速授予令牌。>2.2硬件设计挑战由于两个主要限制，在N1C中以线速实现传输逻辑极具挑战性：时序限制。数据中心的数据包大小中值小于200字节。要使这些小数据包达到IOOGbps,网卡必须每10ns发送一个数据包。因此，每隔10ns,传输逻辑应该确定接下来由哪个活动流来传输哪个数据段。为了做出该决定，它需要使用每个流的一些状态（例如，已确认的数据段、重复的ack、速率/窗口大小等）。当各种传输事件发生时（例如，接收确认或超时），更新这些状态。这些更新可能涉及不可忽略的硬件开销操作，例如搜索位图和数组。为了在处理每个事件时有更多的时间，同时仍然每隔Tons确定下一个据段，我们可以设想将传输事件的处理流水线化到跨多个阶段。当传入事件来自不同的流时，因为它们更新不同的状态使得流水线更容易处理。处理相同流的背靠背事件（例如，在接收确认的同时生成数据段）需要更新到相同的状态，这使得在确保状态一致性的同时流水线事件处理变得困难。因此，我们努力在IOns内处理每个传输事件，而不是快速合并下一个事件的状态，以防它影响相同的流。内存限制：一个典型的数据中心服务器有超过IOoO个并发活动流，其中包含数千字节的动态数据。由于N1C只有几兆字节的高速内存，因此传输协议在NIC上的每个流只能存储几千字节的状态。Tonic的目标是满足这些严格的时序和内存限制，同时通过简单的AP1支持可编程性。为此，我们确定了各种协议中传输逻辑的通用模式，并将这些模式实现为可重用的固定功能模块。这些模式允许我们针对时序和内存优化这些模块，同时通过减少用户必须指定的功能来简化AP1编程。这些模式在表1中进行了总结，并将在下一节中详细讨论，在那里我们将描述TOniC的组件以及这些模式如何影响它们的设计。#ObservationExamp1es1On1ytracka1imitedwindowofsegmentsTCRNDHIRN2On1ykeepafewbitsofsta1epersegmentTCRNDP.1RN.RoCEv231ostsegmentsfirst,newsegmentsnextTCP,NDRIRN.RoCEV241ossdetection:AcksandtimeoutsTCP,NDRIRN5Thethreecommoncreditca1cu1ationpatterns:window,rate,andgranttokensTCP.RoCEv2.NDPTab1eI:Commontransport1ogicpatterns.3. Tonic架构发送端的传输逻辑决定了每个流要传输哪些数据段（数据传递）和何时传输（拥塞控制）。从概念上讲，拥塞控制算法执行Cree1itmanagement,即确定给定流一次可以传输多少字节。数据传输算法执行Segmentse1ection,即确定特定流应该传输哪个连续的字节序列。尽管术语“数据传输”和“拥塞控制”通常与基于TCP的传输协议相关联，但ToniC为传输逻辑提供了一种通用的可编程架构，也可用于其他类型的传输协议，例如接收端驱动和基于RDMA的8传输协议。ToniC利用dataC1eIiVery和creditmanagement之间天然的功能分离，将它们划分为具有独立状态的两个组件（图2）。datade1ivery引擎处理与数据段的生成、跟踪和传输相关的事件，而Credit引擎处理与调整每个流的信用并为具有足够信用的流发送段地址相关的事件。以两个引擎之间的轻量级协调为代价，这种划分方式帮助TOniC在每个周期同时处理多个事件（例如，接收确认和段传输）的同时满足其时序限制。这些事件必须读取其相应流的当前状态，对其进行更新，并将其写回内存以便在下一周期中处理事件。然而，在每个周期中对内存的并发读写成本很高。与使用宽内存来服务所有传输事件不同，分区允许datade1ivery和Creditengines使用更窄的内存来服务于与其特定功能相关的事件，从而满足时间限制。在本节中