时间：2022-12-11 03:47:01
翻译自国外技术博客：鉴于正在进行的提高 TCP Tx零拷贝效率工作[1]，人们开始知道Rx方面能做什么。 Tx零拷贝不需要额外的硬件支持，因此通常很容易实现。 这主要是一种软件练习，用于保存对用户数据的引用，而不是拥有副本。 [1] https://lore.kernel.org/all/cover.1653992701.git.asml.silence @ Gmail.com /硬件执行标头数据分割，并将标头(卡第一个是今天的上游[2]，它依赖于页面大小的块接收数据有效载荷和映射数据。 进程的虚拟地址空间。 更改虚拟地址映射并不便宜，但适合大规模传输。 重要的是，使用零拷贝的APP应用通常比CPU限制更多的DRAM带宽。 这意味着，即使是小传输，也可能需要额外的周期来修改页表，而不是复制数据并耗尽宝贵的DRAM传输。 [2] https://lwn.net/articles/752188 /第二种方法是预先注册用户存储器，直接向网卡DMA数据[3]。 在这种情况下，内存可以是主DRAM或加速器存储器，这对我们来说并不重要。 该模型类似于AF_XDP UMEM的模型。 这取决于标头的数据分割，因为APP应用程序流经网络堆栈，然后内核崩溃。 这是因为APP应用程序不希望可以更改标头。 此外，设备还必须提供足够的流量控制，以将APP应用程序的流量引导至缓冲区/队列——。 我不希望数据最终进入错误的APP应用程序的内存。 当TCP栈处理标头时，它会简单地通知您APP应用程序数据位于何处。 [3] https://lore.kernel.org/netdev/2020072724444.2987641-1-Jonathan.lemon @ Gmail.com/dram (计算加速器虽然netgpu/zctap修补程序已经停滞不前，但这个想法可能已经足够值得最终实现。
展望未来，这两种方法都将处理数据包大小的数据块。 确实，一些硬件支持数据整合( GRO-HW/LRO )，但受到大小、最大努力和延迟引导方面的限制，通常没有进行大规模验证。 已更改硬件以支持零拷贝Rx。 前者为Hitachi，后者为Hitachi转向。 什么样的变更会让我们更上一层楼？ 数据的合并当然可以改善。 LRO依赖于NIC的智能和连接状态的维护，这总是给扩展带来挑战。 另一方面，现代APP应用程序通常事先知道传输的参数，因此可以将处理提示放入数据包中。 接收方需要知道1 )将数据放入哪个内存池/区域，2 )处于哪个偏移量。 可以假设发送者通过RPC层获得这些参数。 发送侧可以将配置信息插入发送的包。 包装在TCP标头的前一个UDP标头中，或用作TCP选项。 一种有用的修改是用TCP序列号表示偏移。 提供基本的TCP序列号和偏移，而不是提供数据包数据到达的绝对偏移。 然后，目标地址计算为
address=mem _ pool [ packet.DMA.mem _ id ].base packet.DMA.offset packet.TCP.seq _ no-packet.DMA.base base 这可以通过在NIC中编程流向一对内存池的授权列表来完成。 不幸的是，完整的列表与流的数量成线性关系。 更好的方法是依赖谷歌的PSP [4]之类的安全协议。 PSP将相关ID分发给发件人，仅在验证后。 如果需要维护完整的列表，则PSPid(4b )比IPv6流密钥( 36B )小得多。 试着巧妙地分配这些——吧。 例如，可以从较高的数字开始分配“直接写入”ID，从较低的数字开始分配不太可靠的连接。 您也可以更改PSP以维护每个内存池，而不是每个设备的密钥，并将内存空间ID合并到密钥派生算法中。 我' [4] https://raw.github user content.com/Google/PSP/main/doc/PSP _ arch _ spec.pdf汇总梦的方案，在PSP头后加上以下菲
16b内存id区域id； 64b -基本偏移量-内存空间中的绝对偏移量32b-传输的TCP序列号的基础。 由于有16个附加比特用于舍入到完整的128b报头，因此可以考虑将代号添加到存储器区域。 当内存区域配置/页表更新异步时，这很有用，以便网卡可以在确认配置完成之前发出读取请求。 在大多数情况下，配置必须在数据到达时完成。 否则，可以回退到非零副本TCP。 我不再为Netronome/Corigine工作了，但这一定是他们的硬件通过固件更新很容易就能支持的。 与PSP本身相似。 这是多么棒的硬件啊……
