A report from the networking miniconference 2014

The second day of the 2014 Kernel Summit included a miniconference for networking subsystem developers. Your editor was unable to attend, but he did get to hear Dave Miller's rapid-fire summary of the topics discussed there. The following report has no hope of being complete — taking notes that quickly is difficult — but, with luck, it covers the most important points.
2014 年内核峰会的第二天安排了一场面向网络子系统开发者的小型会议。虽然编辑本人未能亲自参加，但他听到了 Dave Miller 对会议内容的快速总结。以下报告不可能涵盖全部内容 —— 记笔记的速度很难跟上 —— 但希望能够涵盖最重要的要点。

Dave started with a couple of quick topics, the first of which was the Stream Control Transmission Protocol (SCTP). In general, he said, the networking layer has a lot of highly abstracted code that is shared between protocol implementations. It has always been hard for SCTP to participate in that sharing, though, due to its concept of "associations." The result has been a lot of code duplication in the SCTP subsystem. Now, it seems, there is a new effort afoot to rework the SCTP implementation and unify the code (to a greater extent) with the rest of the networking subsystem.
Dave 首先介绍了几个快速话题，第一个是流控制传输协议（SCTP）。他表示，网络层中有许多高度抽象的代码在多个协议实现之间共享。然而，由于 SCTP 拥有“关联（associations）”的独特概念，它很难参与这种共享。结果就是 SCTP 子系统中存在大量代码重复。现在，似乎有人正在着手重构 SCTP 实现，努力将其与网络子系统的其他部分更大程度地统一起来。

One longstanding suboptimal area in the networking code has been the large hash tables allocated for protocols like TCP at boot time. These tables take a lot of memory; they do not necessarily have to be as big as they are, but there is no way to know what the proper size is when the system is coming up. Now, though, the networking layer has resizeable hash tables protected by the read-copy-update (RCU) mechanism. These tables can be reallocated as necessary, so there is no longer a need to keep large hash tables throughout the life of the system.
网络代码中一个长期存在的问题是像 TCP 这样的协议在系统启动时会分配非常大的哈希表。这些哈希表会占用大量内存；其实它们并不一定需要那么大，但在系统启动时并不知道合适的大小。现在，网络层已经实现了支持动态调整大小的哈希表，并由 RCU（读-拷贝-更新）机制进行保护。这些哈希表可以根据需要重新分配，因此系统在整个生命周期中就不需要一直保留这些巨大的哈希表了。

The extended Berkeley Packet Filter (eBPF) work, Dave noted, remains somewhat controversial. The biggest problem seems to be that eBPF developer Alexei Starovoitov has a great deal of energy and reviewers are having a hard time keeping up. So, Dave said, he is going to start pushing back a bit on these patches to get Alexei to slow things down.
Dave 指出，扩展的伯克利数据包过滤器（eBPF）仍然存在一些争议。最大的问题似乎是 eBPF 的开发者 Alexei Starovoitov 精力充沛，而代码审查人员跟不上他的提交节奏。因此，Dave 表示他将开始对这些补丁进行一定程度的反对，迫使 Alexei 放慢开发速度。

There are co